OCPP 1.6J un 2.0.1 stratēģiskais salīdzinājums komerciāliem uzlādes operatoriem

OCPP 1.6J un 2.0.1 stratēģiskais salīdzinājums globāliem komerciāliem uzlādes operatoriem: tīkla mērogojamības, uzlabotas kiberdrošības, ISO 15118 integrācijas un ilgtermiņa infrastruktūras nākotnes nodrošināšana ilgtspējīgai elektrotransportlīdzekļu izaugsmei.

Kopsavilkums

Elektromobiļu (EV) uzlādes ainava piedzīvo seismiskas pārmaiņas. Paātrinoties globālajai ieviešanai, pamatā esošie komunikācijas protokoli, kas regulē mijiedarbību starp elektromobiļu piegādes iekārtām (EVSE) un uzlādes staciju pārvaldības sistēmām (CSMS), ir kļuvuši par komerciālo uzlādes operatoru (CPO) tehniskās stratēģijas centrālo punktu. Atvērtās uzlādes punktu protokols (OCPP), ko uztur Atvērtās uzlādes alianse (OCA), ir attīstījies no vienkārša ziņojumapmaiņas ietvara par sarežģītu, drošu un ļoti mērogojamu standartu.

Šajā rokasgrāmatā ir sniegta izsmeļoša tehniskā analīze par pāreju no OCPP 1.6J uz OCPP 2.0.1. Mēs izpētām arhitektūras atšķirības, drošības uzlabojumus, ierīču pārvaldības paradigmas un ISO 15118 integrācijas kritisko lomu. Pircējiem un operatoriem šis raksts kalpo kā noteicoša atsauce, lai pieņemtu pārdomātus lēmumus par iepirkumiem un migrāciju strauji augošā tirgū.

1. nodaļa: Elektroautomobiļu uzlādes standartu evolūcija: vēsturisks konteksts

Atvērto uzlādes punktu protokols (OCPP) radās no nepieciešamības pēc sadarbspējas. Elektroautomobiļu uzlādes pirmsākumos aparatūras ražotāji un programmatūras nodrošinātāji izmantoja patentētus protokolus, radot "norobežotus dārzus", kas kavēja konkurenci un inovācijas. OCPP 1.2 un 1.5 ieviešana lika pamatus, taču tieši OCPP 1.6 patiesi vienoja nozari.

1.1 OCPP 1.6J dominance

2015. gadā izlaistā OCPP 1.6 versija ieviesa JSON over WebSockets (1.6J) ieviešanu. Šī atteikšanās no uz SOAP balstītas ziņojumapmaiņas ievērojami samazināja izstrādātāju pieskaitāmās izmaksas un vienkāršoja ieviešanu. Tā ieviesa tādas funkcijas kā viedā uzlāde un papildu statusa paziņojumi, padarot to par nozares standartu gandrīz desmit gadus.

1.2 OCPP 2.0.1 pirmsākumi

Neskatoties uz 1.6J panākumiem, nozares izaugsme atklāja tās ierobežojumus. Drošības problēmas, ierīču pārvaldības sarežģītība un vietējā atbalsta trūkums uzlabotai tīkla integrācijai (V2G) noveda pie OCPP 2.0 izstrādes un pēc tam uzlabotās OCPP 2.0.1 (izlaista 2020. gadā) izstrādes. OCPP 2.0.1 nav tikai atjauninājums; tā ir pilnīga pārveidošana, kuras mērķis ir atbalstīt nākamās paaudzes jaudīgus, viedus un drošus uzlādes tīklus.

2. nodaļa: Pamata komunikācijas paradigmas: JSON, WebSockets un ietvaru struktūras

Lai saprastu atšķirību starp šiem protokoliem, jāaplūko zemākā līmeņa komunikācija. Abi protokoli izmanto JSON, nevis WebSockets, taču šo ziņojumu struktūra un apstrāde ievērojami atšķiras.

2.1 WebSocket slānis

Abas versijas izmanto pastāvīgus WebSocket savienojumus, kas nodrošina pilna dupleksa saziņu. Tas ir ļoti svarīgi reāllaika darbībām, piemēram, uzlādes sesijas apturēšanai no mobilās lietotnes vai tūlītēju kļūmju brīdinājumu saņemšanai.

2.2 Ziņojuma kadra sadalījums

Tipisks OCPP ziņojums sastāv no ziņojuma tipa ID, unikāla ziņojuma ID, darbības nosaukuma un vērtuma.

OCPP 1.6J rāmja piemērs (BootNotification)

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

OCPP 2.0.1 kadra piemērs (BootNotification)

“json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`Ievērojiet palielināto detalizācijas pakāpi versijā 2.0.1.“reason” lauks ļauj CSMS saprast, vai palaišana notika atkārtotas palaišanas, ieslēgšanas vai sargsuņa aktivizēšanas dēļ, tādējādi nodrošinot labāku diagnostikas loģiku.

3. nodaļa: Arhitektūras paradigmas maiņa: ierīces modelis

Visnozīmīgākā tehniskā atkāpe OCPP 2.0.1 versijā ir ieviešanaIerīces modelis.

3.1 1.6J konfigurācijas atslēgu ierobežojumi

OCPP 1.6J versijā aparatūras konfigurācija tika pārvaldīta, izmantojot vienotu “konfigurācijas atslēgu” sarakstu (piemēram,Sirdsdarbības intervāls, Savienojuma taimauts). Uzlādes iekārtām kļūstot sarežģītākām (vairāku savienotāju, integrētu barošanas moduļu, sarežģītu dzesēšanas sistēmu), šis plakanais saraksts kļuva nepārvaldāms. Nebija standartizēta veida, kā aprakstīt stacijas fizisko hierarhiju.

3.2 2.0.1 ierīces modeļa pieeja

OCPP 2.0.1 ievieš hierarhisku modeli, kas sastāv noSastāvdaļasunMainīgie lielumiKomponents varētu būt “kontrolleris”, “savienotājs” vai “barošanas modulis”. Katram komponentam ir mainīgie, kas attēlo tā stāvokli vai konfigurāciju (piemēram,Temperatūra, Spriegums, Maksimālā strāva).

• KomponentsUzlādes stacijas fiziska vai loģiska daļa.
• Mainīgais: Šī komponenta noteikts atribūts.
• RaksturojumsMetadati, kas apraksta mainīgo (vienība, diapazons, piekļuves veids).

Tas ļauj veikt standartizētu uzraudzību. Operators tagad var vaicāt konkrēta barošanas moduļa temperatūru, izmantojot standartizētu ceļu, nevis paļaujoties uz pārdevēja specifiskām patentētām atslēgām.

4. nodaļa: Kiberdrošība: no “labākajām pūlēm” līdz obligātam TLS

Elektroauto uzlādes pirmsākumos drošība bieži vien tika uzskatīta par otrajā plānā. OCPP 1.6J piedāvāja drošības profilus, taču to ieviešana dažādiem piegādātājiem nebija konsekventa.

4.1 Drošības profili 1.6J versijā

OCPP 1.6J definēja trīs drošības profilus:

1. NenodrošinātsVienkārša teksta HTTP/WebSockets.
2. Pamata autentifikācijaTLS ar lietotājvārdu/paroli.
3. Uz sertifikātiem balstītsTLS ar klienta puses sertifikātiem.

Problēma bija tā, ka daudzi lādētāji palika 1. profilā, padarot tos neaizsargātus pret starpnieka (MITM) uzbrukumiem un nesankcionētu kontroli.

4.2 2.0.1 versijas stingrākā nostāja

OCPP 2.0.1 nosaka drošu saziņu. Tajā ir integrētas uzlabotas drošības funkcijas:

• Droši programmaparatūras atjauninājumiObligāta programmaparatūras attēlu parakstīšana un verifikācija.
• Drošības reģistrēšanaDetalizēti žurnāli par ar drošību saistītiem notikumiem (piemēram, neveiksmīgiem pieteikšanās mēģinājumiem, sertifikāta derīguma termiņa beigām).
• Sertifikātu pārvaldībaStandartizēti ziņojumi rotētiem un atjauninātiem sertifikātiem (CSMS vadīti vai stacijas vadīti).
• TLS 1.2/1.3: Atbalsts jaunākajiem šifrēšanas standartiem.

Komerciāliem operatoriem tas samazina masveida tīkla kompromitēšanas risku un nodrošina atbilstību jaunajiem kiberdrošības noteikumiem lietu interneta (IoT) ierīcēm.

5. nodaļa: ISO 15118 integrācija: Plug & Charge un V2G

Elektroautomobiļu uzlādes nākotne nav tikai elektronu pārvietošana; tā ir saistīta ar inteliģentu datu un enerģijas apmaiņu. ISO 15118 ir starptautiskais standarts transportlīdzekļa un tīkla (V2G) komunikācijai, un tā integrācija ar OCPP ir 2.0.1 versijas raksturīgā iezīme.

5.1 Plug & Charge sarežģītība

“Plug & Charge” (PnC) tehnoloģija ļauj vadītājam vienkārši pieslēgt transportlīdzekli elektrotīklam un sākt uzlādi, neizmantojot lietotni vai RFID karti. Tam nepieciešama sarežģīta publiskās atslēgas infrastruktūra (PKI), kurā iesaistīts transportlīdzeklis, uzlādes ierīce, operators un informācijas centrs.

OCPP 1.6J versijā PnC atbalsts nebija iekļauts pamata protokolā. Pārdevējiem bija jāievieš pielāgoti paplašinājumi, kas izraisīja fragmentāciju. OCPP 2.0.1 nodrošina PnC “santehniku”, atbalstot:

• Sertifikāta instalēšanaLīgumu sertifikātu nosūtīšana no CSMS uz EV, izmantojot EVSE.
• AutorizācijaIzmantojot e-Mobility ID (eMAID), kas iegūts no transportlīdzekļa sertifikāta.
• Šifrēta saziņaNodrošināt, ka starp automašīnu un elektrotīklu pārsūtītie sensitīvie norēķinu dati ir aizsargāti.

5.2 Viedā uzlāde un slodzes līdzsvarošana

Lai gan 1,6 J atbalstīja pamata viedo uzlādi (nosūtotIestatīt uzlādes profilu), 2.0.1 to paceļ augstāk. Tā ļauj:

• Ārējo signālu integrācijaReaģēšana reāllaikā uz tīkla frekvences vai vairumtirdzniecības cenu signāliem.
• Dinamiska slodzes pārvaldībaDetalizētāka enerģijas sadales kontrole objektā ar simtiem savienotāju.
• Transportlīdzekļa un tīkla savienojums (V2G)2.0.1 ietver nepieciešamos datu laukus divvirzienu enerģijas plūsmas atbalstam, ļaujot elektrotransportlīdzekļiem darboties kā izkliedētiem enerģijas resursiem (DER) tīklam.

5.3 Lietotāja saskarnes/lietotāja pieredzes uzlabojumi

OCPP 2.0.1 atbalsta informācijas attēlošanu tieši uzlādes ierīces ekrānā vai transportlīdzekļa informācijas panelī, piemēram:

• Cenu noteikšana reāllaikā vietējā valūtā.
• Paredzamais laiks 80% uzlādes stāvokļa sasniegšanai (SoC).
• Detalizēta informācija par čeku pēc aizpildīšanas.

6. nodaļa: Paplašināta ierīču pārvaldība un uzraudzība

CPO gadījumā lādētāja izmaksas nav tikai pirkuma cena; tās ir kopējās īpašumtiesību izmaksas (TCO). Apkope un dīkstāves ir lielākie peļņas slāpētāji. OCPP 2.0.1 to risina, izmantojot izcilas uzraudzības iespējas.

6.1 Notikumu vadīta ziņošana

1.6J versijā CSMS parasti bija jāaptaujā lādētāja statuss vai jāgaida atbilde.Statusa paziņojums. 2.0.1 versijāNotikumu uzraudzībaSistēma ļauj CSMS iestatīt robežvērtības. Piemēram: “Paziņot man tikai tad, ja iekšējā temperatūra pārsniedz 70 °C” vai “Ziņot, ja ieejas spriegums nokrītas zem 200 V”. Tas samazina tīkla noslodzi un ļauj veikt proaktīvu apkopi.

6.2 Darījumu apstrāde: TransactionEvent

Viens no visvairāk kritizētajiem OCPP 1.6J aspektiem bija tā darījumu apstrāde. Sesija, kurā bija iesaistītaSākt darījumuunApturēt darījumuziņojumus, bet, ja radās tīkla pārtraukums, CSMS bieži vien bija grūtības saskaņot norēķinu datus.

OCPP 2.0.1 aizstāj tos ar vienu, stabiluTransakcijas notikumsziņojums. Šis ziņojums tiek izmantots, lai ziņotu par visiem darījuma dzīves cikla posmiem (sākts, atjaunināts, pabeigts). Tas ietver unikāludarījuma IDkas saglabājas pat pēc lādētāja pārstartēšanas, nodrošinot, ka netiek zaudēti uzlādes dati un līdz ar to arī ieņēmumi.

6.3 Uzlabota diagnostika un problēmu novēršana

TheGetLogunDiagnostikas statusa paziņojumsZiņojumi 2.0.1 versijā ir strukturētāki. CPO var pieprasīt konkrētus žurnālu veidus (drošības, diagnostikas, lietotāja) un norādīt laika diapazonu. Tas ļauj attālinātām atbalsta komandām risināt problēmas, nesūtot tehniķi uz objektu, tādējādi ievērojami samazinot darbības izmaksas.

7. nodaļa: Programmatūras atjaunināšanas mehānismi: uzticamība un atcelšana

Programmatūras atjauninājumi ir aparatūras attīstības dzīvības spēks, taču neveiksmīgs atjauninājums var sabojāt lādētāju.

7.1 1.6J atjaunināšanas process

1,6 J dzinējāAtjaunināt programmaparatūruKomanda bija samērā vienkārša. Lādētājs lejupielādētu attēlu un mēģinātu to instalēt. Nebija standartizēta mehānisma daudzpakāpju atjauninājumiem vai pārbaudītām atcelšanām.

7.2 2.0.1 vairāku soļu atjauninājums

OCPP 2.0.1 ievieš sarežģītāku programmaparatūras atjauninājumu dzīves ciklu:

1. LejupielādētLādētājs ielādē attēlu un pārbauda tā kontrolsummu/parakstu.
2. UzstādīšanaAtjauninājums tiek lietots sekundārajā nodalījumā.
3. VerifikācijaSistēma pārbauda, ​​vai jaunā programmaparatūra tiek pareizi ielādēta.
4. AktivizēšanaPrimārā nodalījuma maiņa.

Ja kāds solis neizdodas, protokols nosaka, kā lādētājam jāatgriežas pie iepriekšējās stabilās versijas un jāziņo par konkrēto kļūmes kodu CSMS. Šis uzticamības līmenis nav apspriežams liela mēroga komerciāliem izvietojumiem.

7.3 Paraksta verifikācija

Lai novērstu ļaunprātīgu personu uzbrukumus kompromitētas programmaparatūras augšupielādei, 2.0.1 versija nosaka digitālo parakstu izmantošanu. Lādētājs atteiksies izpildīt jebkuru kodu, kas nav parakstīts ar ražotāja privāto atslēgu, tādējādi pievienojot kritiski svarīgu aizsardzības slāni pret aparatūras līmeņa uzlaušanu.

8. nodaļa: Datu privātums, atbilstība normatīvajiem aktiem un GDPR

Tā kā elektroautomobiļu uzlāde kļūst par ikdienas pakalpojumu, ģenerēto personas datu apjoms ir satriecošs. Viena uzlādes sesija var sasaistīt lietotāja identitāti, viņa transportlīdzekļa atrašanās vietu, ceļošanas paradumus un finanšu informāciju.

8.1 Personu identificējoša informācija (PII) OCPP sistēmā

Saistībā ar Vispārīgo datu aizsardzības regulu (VDAR) Eiropā un līdzīgiem likumiem, piemēram, CCPA Kalifornijā, tādi datu punkti kāidTag(RFID) vaiEVCCID(transportlīdzekļa identifikators) tiek uzskatīta par personas informāciju.

OCPP 2.0.1 nodrošina labākas datu anonimizācijas kontroles. Piemēram,Pielāgoti datilauki ļauj operatoriem saglabāt metadatus, neatklājot personas datus pamata protokola žurnāliem. Turklāt uzlabotie drošības profili nodrošina, ka šie dati tiek šifrēti gan pārsūtīšanas laikā, gan miera stāvoklī.

8.2 Tiesības tikt aizmirstam un datu pārnesamība

2.0.1 ierīces modeļa strukturētais raksturs atvieglo CSMS pakalpojumu sniedzējiem “datu dzēšanas” pieprasījumu ieviešanu. 1.6J sistēmā visu lietotāja ID instanču atrašana dažādās konfigurācijas atslēgās un žurnālos bija manuāls murgs. 2.0.1 versijā skaidra ierīces stāvokļa un darījumu datu atdalīšana nodrošina tīrāku datubāzes arhitektūru.

8.3 Atbilstība lietu interneta (IoT) drošības likumiem

Daudzos reģionos pašlaik tiek pieņemti likumi, kas pieprasa, lai lietu interneta ierīcēm būtu unikālas paroles un droši atjaunināšanas mehānismi. OCPP 2.0.1 obligātais TLS un parakstītā programmaparatūra nav tikai “jaukas” funkcijas — tās ir juridiskas prasības aparatūras pārdošanai tādos tirgos kā Kalifornija un Apvienotā Karaliste.

9. nodaļa: Pircēja perspektīva: kopējās uzturēšanas izmaksas (TCO), ieguldījumu atdeve (ROI) un stratēģiskā migrācija

Komerciālam uzlādes operatoram lēmums pieturēties pie 1,6 J vai pāriet uz 2.0.1 ir finansiāls.

9.1 Ieviešanas izmaksas

• OCPP 1.6JLēti ieviest, plaši atbalsta lēta aparatūra, taču rada augstas slēptās izmaksas uzturēšanas un drošības risku veidā.
• OCPP 2.0.1Nepieciešami jaudīgāki procesori un vairāk atmiņas EVSE. CSMS izstrādes izmaksas ir augstākas protokola sarežģītības dēļ. Tomēr tas piedāvā ievērojamus darbības izmaksu ietaupījumus, pateicoties attālinātai pārvaldībai un labākai uzticamībai.

9.2 Mīts par “vienmērīgu jaunināšanu”

Bieži tiek teikts, ka 1.6J lādētājus var jaunināt uz 2.0.1 versiju, izmantojot programmatūru. Patiesībā tas reti atbilst patiesībai. Atmiņas un centrālā procesora prasības 2.0.1 versijai (īpaši TLS sertifikātu apstrādei un sarežģītās ierīces modeļa JSON parsēšanas veikšanai) bieži vien pārsniedz vecāku 1.6J kontrolleru iespējas.

9.3 Stratēģiskie migrācijas ceļi

CPO jāapsver “hibrīdtīkla” pieeja:

1. Mantotās vietnesTurpināt darbināt 1,6 J esošos mazjaudas maiņstrāvas lādētājus.
2. Jaunas ātrās uzlādes stacijas līdzstrāvas uzlādei: Visiem jaunajiem lieljaudas izvēršanas pasākumiem 2.0.1. mandāts ir paredzēts, lai atbalstītu PnC un V2G.
3. Starpniekservera risinājumiIzmantojiet protokola vārteju, kas CSMS vajadzībām var pārveidot 1.6J ziņojumus 2.0.1 saderīgā formātā, tādējādi nodrošinot vienotu pārvaldības informācijas paneli.

10. nodaļa: Nākotnes prasībām atbilstība: OCPP 2.1 un ceļš uz autonomo uzlādi

Pat 2.0.1 versijai gūstot popularitāti, Open Charge Alliance jau strādā pie OCPP 2.1. Šī nākotnes versija vēl vairāk paplašinās protokola darbības jomu.

10.1 Divvirzienu uzlāde (V2X)

Lai gan 2.0.1 versija atbalsta pamata V2G, 2.1 versija uzlabos saziņu starp transportlīdzekli un mājām (V2H) un transportlīdzekli un ēku (V2B), ļaujot elektrotransportlīdzekļiem apgādāt mājas ar elektroenerģiju elektroenerģijas padeves pārtraukumu laikā vai samazināt komerciālo ēku maksimālo pieprasījumu.

10.2 Atbalsts bezvadu uzlādei

Līdz ar autonomo transportlīdzekļu (AV) parādīšanos manuāla uzlāde vairs nebūs nepieciešama. OCPP 2.1 ietvers standartizētus ziņojumus par induktīvo (bezvadu) uzlādi, izlīdzināšanas pārvaldību un enerģijas pārnesi bez cilvēka iejaukšanās.

10.3 Integrācija ar viedajām pilsētām

Nākotnes versijās, visticamāk, būs paredzēta dziļāka integrācija ar satiksmes pārvaldības sistēmām un atjaunojamās enerģijas prognozēm. Uzlādes stacijām būs iespēja “pieteikties” enerģijas iegādei reāllaika enerģijas tirgos, pārvēršot uzlādes tīklus par milzīgām virtuālām elektrostacijām (VPP).

Tehniskais pielikums: Padziļināta ziņojumu salīdzināšana

Lai sniegtu maksimālu tehnisko dziļumu, mēs tagad analizēsim konkrētas ziņojumu secības un kadru atšķirības starp abām versijām.

A.1 Autorizācijas plūsma

1.6J versijā autorizācija bija bināra atbilde “Accepted” (Pieņemts) vai “Blocked” (Bloķēts).

1.6J Autorizācijas atbilde:“json [3, "123456", { "idTagInfo": { "status": "Pieņemts", "derīguma termiņš": "2026-12-31T23:59:59Z" } }]“

2.0.1 versijā atbildē ir iekļauts vairāk konteksta, piemēram,idTokenlietotāja saskarnes tips un papildu informācija.

2.0.1 Autorizācijas atbilde:“json [3, "987654", { "idTokenInfo": { "status": "Pieņemts", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "Sveicināts atpakaļ, Džon! Jūsu atlikums ir 45,00 ASV dolāri" } } }]“

A.2 Sirdsdarbības un savienojumu pārvaldība

OCPP 2.0.1 optimizē to, kā stacija pierāda, ka tā ir “dzīva”. 1,6 J versijā, jaSirdsdarbībaneizdevās, stacija bieži vien vienkārši turpināja mēģināt vēlreiz. 2.0.1 versijā stacija var izmantotPaziņot par notikumumehānismu, kas ziņo, ka tā savienojums ar sekundāro aizmugursistēmu ir zaudēts, vienlaikus saglabājot sirdsdarbības signālu ar primāro.

A.3 Detalizēta metadatu tabula

Secinājums

Pāreja no OCPP 1.6J uz 2.0.1 nav tikai programmatūras atjauninājums; tā ir fundamentāla elektromobilitātes ekosistēmas evolūcija. Komerciālajiem operatoriem 1.6J pārstāv uzticamu pagātni, savukārt 2.0.1 pārstāv mērogojamu, drošu un inteliģentu nākotni.

Izvēloties 2.0.1 jau šodien, jūs ieguldāt ilgmūžībā. Tas nodrošina, ka jūsu aparatūra būs saderīga ar nākamās paaudzes elektrotransportlīdzekļiem, atbildīs stingrākiem kiberdrošības noteikumiem un būs gatava izmantot ienesīgās V2G un viedtīklu integrācijas iespējas. Tirgum konsolidējoties, operatori ar visizturīgākajām un elastīgākajām protokolu kopām būs tie, kas vadīs šo procesu.

11. nodaļa: Padziļināta izpēte: ziņojumu plūsmas analīze un secības diagrammas

Šajā nodaļā mēs analizējam EVSE un CSMS mijiedarbības secības, lai parādītu darbības atšķirības starp 1.6J un 2.0.1.

11.1 Sāknēšanas un konfigurācijas secība

Kad lādētājs pirmo reizi izveido savienojumu ar tīklu, tam ir jāidentificē sevi un jāsinhronizē sava konfigurācija.

OCPP 1,6 J plūsma:

1. WebSocket savienojumsIzveidots, izmantojot 80. vai 443. portu.
2. BootNotificationStacija nosūta piegādātāju, modeli un sērijas numuru.
3. Iegūt konfigurācijuCSMS pieprasa visas atslēgas, lai pārbaudītu pašreizējo stāvokli.
4. Mainīt konfigurācijuCSMS atjaunina noteiktas atslēgas (piemēram,Sirdsdarbības intervāls).
5. Statusa paziņojumsStacija ziņo par “Pieejama”.

OCPP 2.0.1 plūsma:

1. Droša TLS rokasspiedienaObligāta sertifikātu apmaiņa.
2. BootNotificationIetveriemesls(piemēram,PowerUp).
3. Iegūt bāzes ziņojumuTā vietā, lai pieprasītu visas atslēgas, CSMS pieprasa “bāzes ziņojumu”, kas sniedz pilnu ierīces modeļa hierarhiju.
4. SetVariablesCSMS atjaunina mainīgos. Ņemiet vērā, ka 2.0.1 versija ļauj veikt atomārus atjauninājumus — iestatīt vairākus mainīgos vienā ziņojumā un nodrošināt, ka visi veiksmīgi vai neviens neizdodas.
5. Paziņot par notikumuStacija ziņo par sākotnējiem komponentu stāvokļiem.

11.2 Viedās uzlādes sarunas

Viedā uzlāde ir tā, kur 2.0.1 versija patiesi izceļas, īpaši, ja tiek apstrādāti vairāki uzlādes profili.

1,6 J versijā CSMS nosūtaIestatīt uzlādes profilukas definē steka līmeni un grafiku. Ja stacijai ir vairāki savienotāji, profila apstrāde bieži vien ir neskaidra.

2.0.1 versijāIestatīt uzlādes profiluir nepārprotami saistīts aruzlādes profila mērķis.

• Uzlādes stacijas maksimālais profils: Ierobežo visas stacijas gaisa ieplūdi.
• TXDefaultProfileNoklusējuma vērtība jebkuram jaunam darījumam.
• TXProfile: Attiecas uz notiekošu darījumu.

Turklāt 2.0.1 atbalstaIegūt uzlādes steknes līmeniziņojumu, kas ļauj CSMS redzēt, kuri profili pašlaik ir aktīvi un kā EVSE iekšējais plānotājs tiem piešķir prioritātes.

11.3 Tālvadības ieslēgšana un vadība

Attālinātās komandas, piemēramAttālās palaišanas darījums(1,6 J) ir aizstāti arPieprasījuma sākšanas darījums(2.0.1). Galvenā atšķirība ir lietderīgajā slodzē. 2.0.1 versijā CSMS var ietvertuzlādes profilstieši palaišanas pieprasījumā. Tas nozīmē, ka automašīna var nekavējoties sākt uzlādi ar pareizo jaudas līmeni, negaidot otro ziņojumu, tādējādi samazinot latentumu un uzlabojot tīkla stabilitāti.

12. nodaļa: Zema līmeņa JSON shēmas un lauku salīdzinājumi

Izstrādātājiem un sistēmu integratoriem shēmu izmaiņas ir darbietilpīgākā migrācijas daļa.

12.1 Uzskaitītie tipi (enumi)

OCPP 2.0.1 ievērojami paplašina standartizēto uzskaitījumu skaitu, samazinot nepieciešamību pēc “pielāgotiem” statusa kodiem, kas bija raksturīgi 1.6J ieviešanai.

• Iemeslu uzskaitījumi: Sargsuns, Plānotā atiestatīšana, Attālā atiestatīšana, Jaudas zudums.
• Statusa uzskaitījumi: Aizņemts, Rezervēts, Nav pieejams, Bojāts2.0.1 versija pievienoPieejams, Aizņemts, Rezervēts, Nav pieejams, Bojātsbet ar apakšstatusiem, lai iegūtu sīkāku informāciju.

12.2 Datu tipi un mērvienības

OCPP 2.0.1 formalizē standarta mērvienību (SI) lietošanu. Ja 1,6 J dažreiz atstāja decimāldaļu precizitāti nedefinētu, 2.0.1 izmantodecimāldaļajaudas un enerģijas vērtību veidi, nodrošinot konsekventu norēķinu veikšanu dažādu piegādātāju aparatūrai.

13. nodaļa: Gadījuma izpēte: Globālā CPO migrācija no 1,6 J uz 2,0,1

Apskatīsim hipotētisku scenāriju ar “MegaCharge” — CPO ar 10 000 uzlādes punktiem.

13.1 1. fāze: Audits

MegaCharge atklāja, ka 40% no viņu 1,6 J uzlādes stacijām neatbalsta TLS 1.2. Tas nozīmēja, ka šīs uzlādes stacijas nebija tiesīgas pretendēt uz gaidāmajiem valdības līgumiem.

13.2 2. fāze: CSMS jaunināšana

Tā vietā, lai izveidotu jaunu CSMS, MegaCharge ieviesa “OCPP tulkošanas slāni”. Šis slānis apstrādāja 1.6J savienojumus vecajai aparatūrai un 2.0.1 savienojumus jaunajai aparatūrai, bet mobilajai lietotnei un norēķinu dzinējam nodrošināja vienotu API.

13.3 3. fāze: aparatūras nomaiņa

Vietnēs ar lielu apmeklētāju skaitu MegaCharge nomainīja 1,6 J lādētājus ar 2.0.1 saderīgiem līdzstrāvas ātrajiem lādētājiem. Rezultātā par 15 % samazinājās sesiju skaits ar “Neizdevās sākt”, galvenokārt pateicoties izturīgākajai uzlādei.Transakcijas notikumsapstrāde 2.0.1 versijā.

13.4 Ieguldījumu atdeves (ROI) analīze

Sākotnējās investīcijas bija 2 miljoni ASV dolāru. Tomēr samazinātais apkopes izsaukumu skaits (pateicoties ierīces modeļa diagnostikai) ietaupīja 400 000 ASV dolāru gadā. Turklāt iespēja piedalīties V2G frekvenču reakcijas tirgos radīja papildu 200 000 ASV dolāru gada ieņēmumus. Atmaksāšanās periods bija aptuveni 3,3 gadi.

14. nodaļa: Pircēja galīgais kontrolsaraksts OCPP 2.0.1 iepirkumiem

Novērtējot jaunu aparatūru vai programmatūru, izmantojiet šo kontrolsarakstu, lai nodrošinātu patiesu atbilstību:

14.1 Aparatūras (EVSE) prasības

• [ ]Drošības profila 3 atbalstsVai tas atbalsta klienta puses sertifikātu pārvaldību?
• [ ]Divkodolu procesorsVai ir pietiekami daudz brīvas vietas TLS šifrēšanai un JSON parsēšanai?
• [ ]Drošais elements (SE)Vai platei ir aparatūras uzticamības sakne atslēgu glabāšanai?
• [ ]ISO 15118-2/20 gatavsVai kontrolieris var apstrādāt augsta līmeņa komunikāciju, kas nepieciešama PnC?
• [ ]Attēlošanas iespējasVai aparatūra atbalsta cenas/statusa informācijas rādīšanu, izmantojot OCPP?Datu pārsūtīšanavai vietējās ziņas?

14.2 Programmatūras (CSMS) prasības

• [ ]Ierīces modeļa vizualizācijaVai informācijas panelī var parādīt lādētāja hierarhisko skatu?
• [ ]Sertifikātu iestādes (CA) integrācijaVai CSMS var automātiski izsniegt un rotēt sertifikātus?
• [ ]Darījumu saskaņošanaKā sistēma apstrādā “uzkarināmos” darījumus no 1,6 J mantotajiem lādētājiem?
• [ ]Viedais uzlādes dzinējsVai tas atbalsta 2.0.1 versijas uzlaboto steka līmeņa loģiku?
• [ ]MērogojamībaVai WebSocket apstrādātājs var vienlaikus pārvaldīt vairāk nekā 50 000 pastāvīgu TLS savienojumu?

15. nodaļa: Biežāk sastopamo OCPP ieviešanas problēmu novēršana

Pat ar standartu ieviešana atšķiras. Šeit ir visbiežāk pieļautās problēmas.

15.1 WebSocket taimauti

Daudzi tīkla ugunsmūri slēdz dīkstāvē esošus TCP savienojumus. JaSirdsdarbības intervālsja iestatīts pārāk augsts spriegums, lādētājs var būt atvienots.

• RisinājumsNodrošinātSirdsdarbības intervālsir zemāks par ugunsmūra taimautu (parasti 60–120 sekundes).

15.2 Sertifikātu ķēdes problēmas

Bieži sastopama kļūme 2.0.1 versijā ir kļūda “Neuzticams sertifikāts”. Tā parasti notiek, ja uzlādes ierīcē nav instalēta CSMS saknes sertifikācija.

• RisinājumsIzmantojietInstalēšanas sertifikātsziņojumu nodošanas ekspluatācijā laikā, lai pārliecinātos, ka uzticības ķēde ir pabeigta.

15.3 JSON lietderīgās slodzes lielums

Daži 2.0.1 ziņojumi (piemēram,Iegūt bāzes ziņojumu) var būt ļoti liels. Ja lādētāja buferis ir pārāk mazs, tas atmetīs ziņojumu.

• RisinājumsPārbaudietMaksimālais ziņojuma lielumsmainīgais ierīces modelī un pārliecinieties, vai CSMS ievēro šo ierobežojumu.

16. nodaļa: Reģionālās regulatīvās vides un protokolu mandāti

Pāreju uz OCPP 2.0.1 virza ne tikai tehnoloģijas; tas arvien vairāk ir juridisks jautājums.

16.1 Eiropas Savienība (AFIR)

ES Alternatīvo degvielu infrastruktūras regula (AFIR) nosaka cenu pārredzamību un sadarbspēju. Lai gan tajā nav tieši minēta OCPP 2.0.1, prasība pēc “datu koplietošanas reāllaikā” un “viedās uzlādes” faktiski padara 2.0.1 par vienīgo dzīvotspējīgo standartu jaunai publiskajai infrastruktūrai.

16.2 Ziemeļamerika (NEVI)

Amerikas Savienotajās Valstīs Nacionālās elektrotransportlīdzekļu infrastruktūras (NEVI) formulas programma nosaka, ka uzlādes stacijām jābūt “sadarbspējīgām”. Tādi štati kā Kalifornija iet vēl tālāk, un Kalifornijas Enerģētikas komisija (CEC) cenšas panākt ISO 15118 atbalstu, ko, kā jau apspriedām, vislabāk ieviest, izmantojot OCPP 2.0.1.

16.3 Ķīna un Āzijas un Klusā okeāna reģions

Lai gan Ķīnai ir savi standarti (GB/T), uz eksportu orientētie ražotāji ir ievērojami ieguldījuši OCPP 2.0.1. Tādos tirgos kā Austrālija un Singapūra valdības iepirkumos par publiskajiem uzlādes tīkliem tagad gandrīz tikai tiek norādīts OCPP 2.0.1 ar drošības profilu 3.

17. nodaļa: Ieviešanas koda fragmenti: “Sīkākā informācija”

Lai palīdzētu izstrādātājiem, mēs nodrošinām konceptuālas JSON reprezentācijas sarežģītiem 2.0.1 uzdevumiem.

17.1 Sertifikātu rotācijas plūsma

Kad sertifikāta derīguma termiņš tuvojas beigām, CSMS ir jāaktivizē rotācija.

1. CSMS nosūtaSertifikātsParakstīts:“json [2, "CERT-01", "Parakstīts sertifikāts", { "certificateChain": "-----SERTIFIKĀTA SĀKUMS-----\n...\n-----SERTIFIKĀTA BEIGAS-----", "certificateType": "V2G" }]“

2. Stacija atbildPieņemts:“json [3, "CERT-01", { "statuss": "Pieņemts" }]“

3. Stacija sūtaDrošības notikuma paziņojums:“json [2, "EVT-99", "Drošības notikuma paziņojums", { "tips": "Sertifikāta pagriešana", "laika zīmogs": "2026-08-09T10:00:00Z" }]“

17.2 Tīklam pielāgota uzlādes profila iestatīšana

Iedomājieties, ka tīkla operatoram ir jāsamazina enerģijas patēriņš tīklā.

CSMS nosūtaIestatīt uzlādes profilu:“json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "chargingProfileKind": "Absolūts", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } } }]“

18. nodaļa: Visaptverošs OCPP 2.0.1 terminu glosārijs

Lai nodrošinātu skaidrību visām ieinteresētajām personām, mēs piedāvājam paplašinātu glosāriju.

• CSMS (uzlādes staciju pārvaldības sistēma): Aizmugurējā mākoņplatforma, kas kontrolē uzlādes stacijas.
• EVSE (elektrisko transportlīdzekļu piegādes aprīkojums)Fiziskā uzlādes stacija.
• OCPP (atvērtā uzlādes punkta protokols)Valoda, kurā viņi runā.
• OCA (Atvērtās maksas alianse)Organizācija, kas raksta valodu.
• ISO 15118Protokols starp automašīnu un lādētāju.
• PnC (pievieno un uzlādē)Lietotāja pieredze, ko nodrošina ISO 15118 un OCPP 2.0.1.
• V2G (transportlīdzekļa un tīkla savienojums): Jaudas nosūtīšana no automašīnas atpakaļ uz elektrotīklu.
• V2X (transportlīdzekļa un visa cita ierīce)Apvienojošais termins V2G, V2H un V2B apzīmēšanai.
• TLS (transporta slāņa drošība)Šifrēšana, kas nodrošina datu drošību.
• PKI (publiskās atslēgas infrastruktūra)Digitālo sertifikātu sistēma, ko izmanto drošībai.
• JSON (JavaScript objektu notācija)Ziņojumu formāts.
• WebSocketPastāvīgā savienojuma “caurule”, caur kuru plūst ziņojumi.
• Ierīces modelisHierarhiskā metode 2.0.1 apraksta aparatūru.
• KomponentsAparatūras daļa (piemēram, savienotājs).
• MainīgaisKomponentes īpašība (piemēram, Status).
• AtribūtsMetadati par mainīgo (piemēram, Vērtība, Mainīgums).
• Transakcijas notikumsVienotais ziņojums visiem sesijas datiem 2.0.1 versijā.
• SirdsdarbībaPeriodiskais signāls “Esmu dzīvs”.
• BootNotificationSignāls “Sveiki, esmu klāt”, kad lādētājs ieslēdzas.
• Datu pārsūtīšanaVispārīgs ziņojums pārdevēja paplašinājumiem (lietojiet piesardzīgi!).

Noslēguma domas: navigācija daudzprotokolu laikmetā

Kā pircējam vai operatoram vissvarīgākais secinājums ir tāds, ka mēs ieejam tirgūdaudzprotokolu ēraNākamo 3–5 gadu laikā 1,6 J un 2,0,1 pastāvēs līdzās. Tomēr līdzsvars strauji mainās.

Izvēloties OCPP 2.0.1 jau šodien, jūs ne tikai iegādājaties protokolu; jūs iegādājaties apdrošināšanu. Jūs nodrošināt, ka jūsu tīkls var pielāgoties jaunām automašīnām, jauniem likumiem un jaunām ieņēmumu plūsmām. 2.0.1 sarežģītība ir progresa cena — cena, kas atmaksājas, uzlabojot darbības laiku, samazinot risku un nodrošinot izcilu klientu pieredzi.

Komerciālā uzlādes sistēma vairs nav nišas nozare; tā ir nākotnes transporta sistēmas mugurkauls. Veidojiet šo mugurkaulu uz pēc iespējas stabilāka pamata: OCPP 2.0.1.

19. nodaļa: Izstrāde OCPP 2.0.1: programmatūras inženieru labākā prakse

Pāreja no 1.6J koda bāzes uz 2.0.1 nav refaktors; tā ir pārrakstīšana. Izstrādātājiem ir jāpieņem atšķirīgs mentālais modelis.

19.1 Asinhronitātes pieņemšana

Lai gan WebSockets pēc savas būtības ir asinhroni, 2.0.1 sarežģītība nozīmē, ka viens pieprasījums (piemēram,Iegūt bāzes ziņojumu) apstrāde resursu ierobežotā EVSE var aizņemt vairākas sekundes. CSMS izstrādātājiem ir jāievieš stabila taimauta un atkārtotas mēģināšanas loģika, kas ņem vērā dažādu aparatūras piegādātāju atšķirīgos apstrādes ātrumus.

19.2 Efektīva JSON parsēšana

JSON parsēšana var būt procesora ietilpīga. EVSE programmaparatūras gadījumā izstrādātājiem jāizmanto uz straumi balstīti parsētāji, nevis visa vērtuma ielāde RAM. Tas ir īpaši svarīgiPaziņot par notikumuziņojumi, kas vienā kadrā var saturēt simtiem mainīgo atjauninājumu.

19.3 Valsts mašīnas apstrāde

2.0.1 versijā transakcijas stāvokļa mašīna ir stingrāka nekā 1.6J versijā. Izstrādātājiem ir stingri jāievēro pārejas noteikumi.Transakcijas notikumsPiemēram, jūs nevarat nosūtītBeidziespasākums, vispirms nenosūtotSāktspasākums šim konkrētajam gadījumamdarījuma ID.

20. nodaļa: Testēšana, validācija un OCPP atbilstības pārbaudes rīks (OCTT)

Sadarbspēja ir OCPP solījums, taču tā tiek realizēta tikai ar stingras testēšanas palīdzību.

20.1 OCA sertifikācijas loma

Open Charge Alliance piedāvā sertifikācijas programmu. Pircējiem jāmeklē marķējums “OCPP 2.0.1 Certified”. Šī sertifikācija garantē, ka ieviešana ir izturējusi virkni automatizētu testu, kas aptver visus obligātos profilus.

20.2 OCTT izmantošana

OCPP atbilstības pārbaudes rīks (OCTT) ir testēšanas zelta standarts. Tas simulē gan CSMS, gan EVSE.

• EVSE ražotājiemIzmantojiet OCTT, lai pārbaudītu, vai jūsu stacija apstrādā “laimīgā ceļa” scenārijus un robežgadījumus (piemēram, tīkla pārtraukumus programmaparatūras atjaunināšanas laikā).
• CSMS pakalpojumu sniedzējiemIzmantojiet OCTT, lai nodrošinātu, ka jūsu aizmugursistēma spēj apstrādāt milzīgo ziņojumu dažādību un stingrās 2.0.1 drošības prasības.

20.3 Lauka testēšana un sadarbspējas festivāli

Papildus automatizētai testēšanai OCA organizē “Plugfests”, kuros pārdevēji piedāvā savu aparatūru un programmatūru testēšanai reālās dzīves situācijās. Šeit tiek atklātas un novērstas visnelielākās kļūdas, piemēram, sertifikātu nesaderība vai nelielas JSON formatēšanas atšķirības.

21. nodaļa: Padziļināta salīdzinošā tabula: vairāk nekā 60 OCPP 2.0.1 darbības

Lai sniegtu pilnīgu pārskatu, mēs kategorizējam 2.0.1 versijas galvenos ziņojumus un salīdzinām tos ar to 1.6J versijas analogiem.

21.1 Nodrošināšana un konfigurācija

21.2 Darījumu apstrāde

21.3 Drošības un programmaparatūras pārvaldība

21.4 Ko tabula nozīmē jūsu tīklam

Tabulā ir nepārprotams viens punkts: OCPP 2.0.1 nav kosmētisks 1.6J pārdēvējums. Jaunās ziņojumu saimes — tipizētie mainīgie, notikumu vadītas transakcijas un sertifikātu pārvaldība — ir nepieciešamais savienojums un uzlāde, viedā uzlāde un normatīvo pārskatu sniegšana. Lādētāju, kas runā tikai 1.6J, var aprīkot ar vārteju, bet CSMS, kas runā tikai 1.6J, nevar nodrošināt drošības modeli, ko arvien vairāk pieprasa regulatori un autoražotāji. Novērtējot aparatūru, “2.0.1 gatavs” nozīmē, ka programmaparatūra tiek piegādāta šodien, nevis nākamgad. Un tā kā OCPP 2.0.1 darbojas ar JSON-over-WebSocket, nevis 1.6J SOAP transportu, ziņojumu plūsmas ir vieglākas un daudz vieglāk atkļūdojamas — praktiska priekšrocība, ko jūsu IT komanda jutīs jau no pirmās dienas.

22. nodaļa: Secinājums: lēmuma pieņemšana par jaunināšanu

Komerciālajam operatoram praktiskie norādījumi ir skaidri:

• Jaunām izvietošanām pēc noklusējuma vajadzētu būt OCPP 2.0.1.Drošības modelis, sertifikātu apstrāde un ISO 15118 integrācija ir 2026. gada normatīvās vides priekšnoteikumi.
• Esošie 1,6J dzinēju autoparki nav apmetušies uz spriedzes robežas.Pārvaldītās vārtejas un divu protokolu CSMS platformas aizpilda plaisu, kamēr jūs pakāpeniski ieviešat 2.0.1 bāzes aparatūru.
• Pārbaudi, pirms uzticies.Izmantojiet OCTT, plugfestus un pakāpenisku ieviešanu — sadarbspēja ir pierādīta darbībā, nevis tiek pieņemta no datu lapas.
• Pieprasiet rakstisku migrācijas ceļu.Jūsu lādētāja pārdevējam vajadzētu publicēt programmaparatūras plānu no 1.6J līdz 2.0.1 ar datumiem, nevis neskaidriem solījumiem.

Aicinājums uz rīcību: Runājiet ar MIDA Power par savu protokola stratēģiju

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.