OCPP 1.6J eta 2.0.1en arteko konparaketa estrategikoa kargatzeko operadore komertzialentzat

OCPP 1.6J eta 2.0.1en arteko behin betiko konparaketa estrategikoa kargatzeko operadore komertzial globalentzat: sarearen eskalagarritasuna, zibersegurtasun aurreratua, ISO 15118 integrazioa eta epe luzerako azpiegituren etorkizunerako prestaketa ibilgailu elektrikoen hazkunde jasangarrirako

Laburpen exekutiboa

Ibilgailu elektrikoen (EV) kargatzeko paisaia aldaketa sismiko bat jasaten ari da. Mundu mailako adopzioa bizkortzen den heinean, Ibilgailu Elektrikoen Hornikuntza Ekipamenduen (EVSE) eta Kargatzeko Estazioen Kudeaketa Sistemen (CSMS) arteko elkarrekintza arautzen duten oinarrizko komunikazio-protokoloak Kargatzeko Operadore Komertzialen (CPO) estrategia teknikoaren ardatz bihurtu dira. Open Charge Alliance-k (OCA) mantentzen duen Karga Puntu Irekiaren Protokoloa (OCPP) mezularitza-esparru sinple batetik estandar sofistikatu, seguru eta oso eskalagarri batera eboluzionatu du.

Gida honek OCPP 1.6J-tik OCPP 2.0.1-erako trantsizioaren analisi tekniko sakona eskaintzen du. Arkitektura-desberdintasunak, segurtasun-hobekuntzak, gailuen kudeaketa-paradigmak eta ISO 15118 integrazioaren funtsezko eginkizuna aztertzen ditugu. Erosle eta operadoreentzat, artikulu hau erreferentzia gisa balio du azkar heltzen ari den merkatu batean erosketa eta migrazio erabaki informatuak hartzeko.

1. kapitulua: Ibilgailu elektrikoen kargatzeko estandarren bilakaera: testuinguru historikoa

Open Charge Point Protocol (OCPP) interoperabilitate beharretik sortu zen. Ibilgailu elektrikoak kargatzeko lehen egunetan, hardware fabrikatzaileek eta software hornitzaileek protokolo jabedunak erabiltzen zituzten, lehia eta berrikuntza oztopatzen zituzten "lorategi hesituak" sortuz. OCPP 1.2 eta 1.5 bertsioen sarrerak oinarriak ezarri zituen, baina OCPP 1.6 izan zen industria benetan batu zuena.

1.1 OCPP 1.6J-ren nagusitasuna

2015ean kaleratua, OCPP 1.6 bertsioak JSON WebSockets-en gaineko (1.6J) inplementazioa aurkeztu zuen. SOAP oinarritutako mezularitzatik aldentze honek nabarmen murriztu zuen gastua eta sinplifikatu zuen garatzaileen inplementazioa. Kargatze adimenduna eta egoera-jakinarazpen gehigarriak bezalako funtzioak sartu zituen, ia hamarkada batez industria-estandar bihurtuz.

1.2 OCPP 2.0.1-en jatorria

1.6J-ren arrakasta izan arren, industriaren hazkundeak bere mugak agerian utzi zituen. Segurtasun arazoek, gailuen kudeaketaren konplexutasunak eta sare elektrikoaren integrazio aurreratuaren (V2G) euskarri natibo faltak OCPP 2.0 garatzera eraman zuten, eta ondoren, OCPP 2.0.1 findua (2020an kaleratua). OCPP 2.0.1 ez da eguneratze bat soilik; hurrengo belaunaldiko kargatzeko sare potentzial, adimendun eta seguruak laguntzeko diseinatutako birdiseinu osoa da.

2. kapitulua: Oinarrizko komunikazio-paradigmak: JSON, WebSocket-ak eta marko-egiturak

Protokolo hauen arteko aldea ulertzeko, behe-mailako komunikazioa aztertu behar da. Bi protokoloek JSON erabiltzen dute WebSocket-en gainean, baina mezu hauen egitura eta kudeaketa nabarmen desberdinak dira.

2.1 WebSocket geruza

Bi bertsioek WebSocket konexio iraunkorrak erabiltzen dituzte, eta horrek komunikazio full-duplexa ahalbidetzen du. Hau ezinbestekoa da denbora errealeko eragiketetarako, hala nola kargatzeko saio bat mugikorretarako aplikazio batetik gelditzeko edo berehalako akatsen alertak jasotzeko.

2.2 Mezu-markoen banaketa

OCPP mezu tipiko batek mezu motaren IDa, mezu ID bakarra, ekintzaren izena eta karga ditu.

OCPP 1.6J markoaren adibidea (BootNotification)

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

OCPP 2.0.1 markoaren adibidea (BootNotification)

"json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`Kontuan izan 2.0.1 bertsioan granularitate handiagoa dagoela.`reason` eremuak CSMS-ri ulertzen laguntzen dio abiaraztea berrabiarazi, pizte edo watchdog abiarazte baten ondorioz izan den, diagnostiko logika hobea ahalbidetuz.

3. kapitulua: Arkitektura-paradigma aldaketa: Gailuaren eredua

OCPP 2.0.1-en aldaketa tekniko esanguratsuena honako hauen sarrera da:Gailuaren modeloa.

3.1 1.6J konfigurazio-giltzen mugak

OCPP 1.6J-n, hardwarearen konfigurazioa "Konfigurazio-giltzen" zerrenda lau baten bidez kudeatzen zen (adibidez,Bihotz-taupada tartea, Konexio-denbora-muga). Kargagailuak konplexuagoak bihurtu ahala (konektore anitzekoak, potentzia-modulu integratuak, hozte-sistema konplexuak), zerrenda laua kudeatzeaz gain, ez zegoen estazio baten hierarkia fisikoa deskribatzeko modu estandarizaturik.

3.2 2.0.1 Gailu Ereduaren Ikuspegia

OCPP 2.0.1-ek eredu hierarkiko bat aurkezten du, honako hauek dituena:OsagaiaketaAldagaiakOsagai bat "Kontrolatzailea", "Konektorea" edo "PowerModule" izan daiteke. Osagai bakoitzak bere egoera edo konfigurazioa adierazten duten aldagaiak ditu (adibidez,Tenperatura, Tentsioa, Gehienezko Korrontea).

• OsagaiaKargatzeko estazioaren zati fisiko edo logikoa.
• Aldagaia: Osagai horren atributu espezifiko bat.
• EzaugarriakAldagaia deskribatzen duten metadatuak (unitatea, barrutia, sarbide mota).

Horri esker, monitorizazio estandarizatua egin daiteke. Operadore batek orain potentzia-modulu espezifiko baten tenperatura kontsulta dezake bide estandarizatu bat erabiliz, saltzailearen jabedun gakoetan oinarritu beharrean.

4. kapitulua: Zibersegurtasuna: “Ahalegin onena”-tik TLS derrigorrezkora

Ibilgailu elektrikoak kargatzen hasi zirenean, segurtasuna askotan bigarren mailako kontua izaten zen. OCPP 1.6J-k segurtasun-profilak eskaintzen zituen, baina inplementazioa ez zen koherentea saltzaileen artean.

4.1 Segurtasun-profilak 1.6J-n

OCPP 1.6J-k hiru segurtasun-profil definitu zituen:

1. Segurtasunik gabekoaTestu arrunteko HTTP/WebSocket-ak.
2. Oinarrizko autentifikazioaTLS erabiltzaile-izen/pasahitzarekin.
3. Ziurtagirietan oinarritutakoTLS bezero-aldeko ziurtagiriekin.

Arazoa zen kargagailu asko 1. profilean geratzen zirela, eta horrek man-in-the-middle (MITM) erasoen eta baimenik gabeko kontrolen aurrean zaurgarri uzten zituela.

4.2 2.0.1-en jarrera gogortua

OCPP 2.0.1-ek komunikazio segurua agintzen du. Segurtasun-ezaugarri aurreratuak integratzen ditu modu natiboan:

• Firmware eguneratze seguruakFirmware irudien sinadura eta egiaztapen derrigorrezkoa.
• Segurtasun erregistroaSegurtasunarekin lotutako gertaeren erregistro zehatzak (adibidez, saioa hasteko huts egindako saiakerak, ziurtagiriaren iraungipena).
• Ziurtagirien kudeaketaTxandakatu eta eguneratutako ziurtagirien mezu estandarizatuak (CSMSk zuzenduta edo estaziok zuzenduta).
• TLS 1.2/1.3: Azken enkriptazio estandarren euskarria.

Operadore komertzialentzat, honek sareko kalte masiboen arriskua murrizten du eta IoT gailuetarako zibersegurtasun-araudi berriekin bat datorrela ziurtatzen du.

5. kapitulua: ISO 15118 integrazioa: Konektatu eta kargatu eta V2G

Ibilgailu elektrikoen kargatzearen etorkizuna ez da soilik elektroiak mugitzea; datuen eta energiaren truke adimenduna da. ISO 15118 ibilgailuaren eta sare elektrikoaren arteko (V2G) komunikaziorako nazioarteko estandarra da, eta OCPPrekin duen integrazioa da 2.0.1 bertsioaren ezaugarri nagusia.

5.1 Konektatu eta kargatzearen konplexutasuna

Plug & Charge (PnC) funtzioak gidariari ibilgailua konektatu eta kargatzen hasteko aukera ematen dio aplikazio edo RFID txartelik erabili gabe. Horretarako, ibilgailua, kargagailua, operadorea eta informazio-zentroa barne hartzen dituen Giltza Publikoko Azpiegitura (PKI) konplexu bat behar da.

OCPP 1.6J-n, oinarrizko protokoloan ez zegoen PnC euskarririk. Saltzaileek luzapen pertsonalizatuak inplementatu behar izan zituzten, eta horrek zatikatzea eragin zuen. OCPP 2.0.1-ek PnC-ren "iturgintza" eskaintzen du honako hauek onartuz:

• Ziurtagiriaren instalazioaKontratu-ziurtagiriak CSMStik EVra pasatzea EVSEren bidez.
• BaimenaIbilgailuaren ziurtagiritik eratorritako e-Mobility IDa (eMAID) erabiliz.
• Komunikazio enkriptatuaAutoaren eta sare elektrikoaren artean igarotzen diren fakturazio-datu sentikorrak babestuta daudela ziurtatzea.

5.2 Kargatze Adimenduna eta Karga-Orekatzea

1.6J-k oinarrizko kargatze adimenduna onartzen zuen bitartean (bidaltzeaEzarri kargatzeko profila), 2.0.1 bertsioak hau hobetzen du. Honako hau ahalbidetzen du:

• Kanpoko seinaleen integrazioaSarearen maiztasunaren edo handizkako prezioen seinaleei denbora errealeko erantzuna.
• Karga Kudeaketa DinamikoaEhunka konektore dituen gune batean energia-banaketaren gaineko kontrol xeheagoa.
• Ibilgailutik Sare Elektrikora (V2G)2.0.1 bertsioak energia-fluxu bidirekzionala onartzeko beharrezko datu-eremuak barne hartzen ditu, ibilgailu elektrikoek sare elektrikoarentzako energia-baliabide banatu (DER) gisa jarduteko aukera emanez.

5.3 Erabiltzailearen UI/UX hobekuntzak

OCPP 2.0.1-ek informazioa kargagailuaren pantailan edo ibilgailuaren aginte-panelean zuzenean bistaratzea onartzen du, hala nola:

• Denbora errealeko prezioak tokiko monetan.
• % 80ko karga-egoerara (SoC) iristeko aurreikusitako denbora.
• Amaitutakoan, ordainagiriari buruzko informazio zehatza.

6. kapitulua: Gailuen kudeaketa eta monitorizazio aurreratua

CPO batentzat, kargagailu baten kostua ez da erosketa prezioa bakarrik; Jabetza Kostu Osoa (TCO) da. Mantentze-lanak eta geldialdiak dira irabazien hiltzaile handienak. OCPP 2.0.1-ek horri aurre egiten dio monitorizazio gaitasun hobetuen bidez.

6.1 Gertaeretan oinarritutako txostenak

1.6J-an, CSMS-ak normalean kargagailuari egoera galdekatu edo erantzun baten zain egon behar zuen.Egoera-jakinarazpena2.0.1ean,Gertaeren jarraipenaSistemak CSMSari atalaseak ezartzeko aukera ematen dio. Adibidez: "Barneko tenperatura 70 °C-tik gorakoa bada bakarrik jakinarazi" edo "Sarrerako tentsioa 200 V-tik behera jaisten bada jakinarazi". Horrek sareko trafikoa murrizten du eta mantentze proaktiboa ahalbidetzen du.

6.2 Transakzioen kudeaketa: TransactionEvent

OCPP 1.6J-ren alderdirik kritikatuenetako bat transakzioen kudeaketa izan zen. Saio batek parte hartu zuenHasi TransakzioaetaGelditu Transakzioamezuak, baina sareko etenaldiren bat gertatzen bazen, CSMSak askotan zailtasunak izaten zituen fakturazio-datuak bateratzeko.

OCPP 2.0.1-ek hauek ordezkatzen ditu bakarra eta sendoa den batekinTransakzioGertaeramezua. Mezu hau transakzio baten bizi-zikloaren etapa guztien berri emateko erabiltzen da (Hasita, Eguneratuta, Amaituta). Mezu bakarra daukatransakzio IDakargagailua berrabiarazi arren ere jarraitzen du, kargatzeko daturik —eta, beraz, diru-sarrerarik— galtzen ez dela bermatuz.

6.3 Diagnostiko eta arazoen konponketa hobetuak

TheLortu erregistroaetaDiagnostikoen EgoeraJakinarazpena2.0.1 bertsioko mezuak egituratuagoak dira. CPOek erregistro mota espezifikoak eska ditzakete (Segurtasuna, Diagnostikoa, Erabiltzailea) eta denbora-tartea zehaztu. Horri esker, urruneko laguntza-taldeek arazoak konpondu ditzakete teknikari bat gunera bidali gabe, OpEx nabarmen murriztuz.

7. kapitulua: Firmware eguneratzeko mekanismoak: fidagarritasuna eta atzera egitea

Firmware eguneraketak hardware ebolutiboen funtsezkoak dira, baina eguneratze huts batek kargagailua hondatu dezake.

7.1 1.6J eguneratze prozesua

1,6 J-tan,Firmwarea eguneratuKomandoa nahiko sinplea zen. Kargagailuak irudia deskargatzen zuen eta instalatzen saiatzen zen. Ez zegoen mekanismo estandarizaturik etapa anitzeko eguneratzeetarako edo egiaztatutako atzera-egiteetarako.

7.2 2.0.1 urrats anitzeko eguneratzea

OCPP 2.0.1-ek firmware eguneratzeetarako bizi-ziklo sofistikatuagoa aurkezten du:

1. DeskargatuKargagailuak irudia eskuratu eta bere kontrol-batura/sinadura egiaztatzen du.
2. Instalazioa: Eguneratzea bigarren mailako partizio bati aplikatzen zaio.
3. EgiaztapenaSistemak firmware berria behar bezala abiarazten den egiaztatzen du.
4. Aktibazioa: Lehen mailako partizioa aldatu da.

Urrats baten bat huts egiten badu, protokoloak kargagailuak aurreko bertsio egonkorrera nola itzuli behar duen definitzen du eta akats-kode espezifikoa CSMSri nola jakinarazi behar dion. Fidagarritasun-maila hau ezinbestekoa da eskala handiko merkataritza-hedapenetarako.

7.3 Sinaduraren egiaztapena

Gaiztoek firmware kaltetua igotzea saihesteko, 2.0.1 bertsioak sinadura digitalak erabiltzea agintzen du. Kargagailuak fabrikatzailearen gako pribatuak sinatu ez duen koderik exekutatzeari uko egingo dio, hardware mailako hackeoen aurkako babes-geruza kritiko bat gehituz.

8. kapitulua: Datuen pribatutasuna, araudi-betetzea eta GDPR

Ibilgailu elektrikoak kargatzea eguneroko erabilera bihurtzen ari den heinean, sortzen den datu pertsonal kopurua izugarria da. Kargatzeko saio bakar batek erabiltzailearen identitatea, ibilgailuaren kokapena, bidaia-ereduak eta finantza-informazioa lotu ditzake.

8.1 Informazio Pertsonal Identifikagarria (PII) OCPP-n

Europako Datuen Babeserako Erregelamendu Orokorraren (GDPR) eta Kaliforniako CCPA bezalako antzeko legeen testuinguruan, datu-puntuak, hala nola...idTag(RFID) edoEVCCID(Ibilgailuaren identifikatzailea) PIItzat hartzen dira.

OCPP 2.0.1-ek datuen anonimizaziorako kontrol hobeak eskaintzen ditu. Adibidez,Datu pertsonalizatuakeremuek operadoreei metadatuak gordetzeko aukera ematen diete PII protokolo nagusiaren erregistroei erakutsi gabe. Gainera, segurtasun-profil hobetuek datu hauek enkriptatuta daudela ziurtatzen dute bai bidean bai geldirik daudenean.

8.2 Ahaztua izateko eskubidea eta datuen eramangarritasuna

2.0.1 Gailu Ereduaren izaera egituratuak errazten die CSMS hornitzaileei "datuak ezabatzeko" eskaerak ezartzea. 1.6J sistema batean, erabiltzaile baten IDaren instantzia guztiak konfigurazio-gako eta erregistro desberdinetan aurkitzea eskuzko amesgaizto bat zen. 2.0.1ean, gailuaren egoeraren eta transakzio-datuen arteko bereizketa argiak datu-baseen arkitektura garbiagoa ahalbidetzen du.

8.3 Gauzen Interneteko Segurtasun Legeen Betetzea

Eskualde askok Interneteko gauzen gailuek pasahitz bakarrak eta eguneratze-mekanismo seguruak izatea eskatzen duten legeak onartzen ari dira orain. OCPP 2.0.1-en derrigorrezko TLS eta sinatutako firmwarea ez dira soilik "edukitzeko politak" diren ezaugarriak, baizik eta Kalifornia eta Erresuma Batua bezalako merkatuetan hardwarea saltzeko legezko eskakizunak dira.

9. kapitulua: Eroslearen ikuspegia: TCO, ROI eta migrazio estrategikoa

Kargatzeko operadore komertzial batentzat, 1,6 J-rekin jarraitzeko edo 2.0.1-era aldatzeko erabakia finantza-kontua da.

9.1 Inplementazio-kostua

• OCPP 1.6JMerkea da ezartzeko, hardware merkeak asko laguntzen du, baina mantentze-lanetan eta segurtasun-arriskuetan kostu ezkutu handiak ditu.
• OCPP 2.0.1Prozesadore indartsuagoak eta memoria gehiago behar ditu EVSE-n. CSMSren garapen-kostuak handiagoak dira protokoloaren konplexutasunagatik. Hala ere, Operazio-gastuetan aurrezpen handiak eskaintzen ditu urruneko kudeaketaren eta fidagarritasun hobearen bidez.

9.2 “Berritze leuna” mitoa

Askotan esaten da 1.6J-ko kargagailuak software bidez 2.0.1era eguneratu daitezkeela. Egia esan, gutxitan gertatzen da hori. 2.0.1erako memoria eta CPU eskakizunak (batez ere TLS ziurtagiriak kudeatzea eta Gailu Ereduaren JSON analisi konplexua) askotan 1.6J kontrolagailu zaharragoen gaitasunak gainditzen dituzte.

9.3 Migrazio Bide Estrategikoak

CPOek "Sare Hibridoa" ikuspegia kontuan hartu beharko lukete:

1. Legatu guneakJarraitu 1,6 J-ko potentzia txikiko korronte alternoko kargagailuekin.
2. DC kargatzeko gune azkar berriak2.0.1 agindua potentzia handiko inplementazio berri guztietarako PnC eta V2G onartzeko.
3. Proxy SoluzioakErabili 1.6J mezuak CSMSrako 2.0.1 formatuarekin bateragarri den formatu batera itzul ditzakeen protokolo-pasabide bat, kudeaketa-panel bateratu bakarra ahalbidetuz.

10. kapitulua: Etorkizunerako prestaketa: OCPP 2.1 eta karga autonomorako bidea

2.0.1 bertsioak indarra hartzen ari den arren, Open Charge Alliance dagoeneko OCPP 2.1-en lanean ari da. Etorkizuneko bertsio honek protokoloaren irismena are gehiago zabalduko du.

10.1 Bi norabideko kargatzea (V2X)

2.0.1 bertsioak oinarrizko V2G onartzen duen arren, 2.1 bertsioak Ibilgailutik Etxerako (V2H) eta Ibilgailutik Eraikinera (V2B) komunikazioa hobetuko du, ibilgailu elektrikoek etxeak argindar mozketetan hornitu ahal izan ditzaten edo eraikin komertzialetako eskaera punta murrizteko aukera emanez.

10.2 Haririk gabeko kargatzeko laguntza

Ibilgailu autonomoak (AV) agertzen diren heinean, eskuzko konektatzea zaharkituta geratuko da. OCPP 2.1 bertsioak karga induktiborako (haririk gabekoa) mezu estandarizatuak barne hartuko ditu, lerrokatzea eta energia transferentzia gizakiaren esku-hartzerik gabe kudeatuz.

10.3 Hiri Adimendunekin Integrazioa

Etorkizuneko bertsioek trafikoaren kudeaketa sistemekin eta energia berriztagarrien iragarpenekin integrazio sakonagoa izango dute ziurrenik. Kargagailuek energia lortzeko "eskaintza" egin ahal izango dute denbora errealeko energia-merkatuetan, kargatzeko sareak zentral elektriko birtual erraldoi (VPP) bihurtuz.

Eranskin teknikoa: Mezuen konparazioetan sakontzea

Sakontasun tekniko gorena emateko, orain bi bertsioen arteko mezu-sekuentzia espezifikoak eta fotograma-desberdintasunak aztertuko ditugu.

A.1 Baimen-fluxua

1.6J-n, baimena "Onartuta" edo "Blokeatuta" erantzun bitarra zen.

1.6J Baimen Erantzuna:"json [3, "123456", { "idTagInfo": { "egoera": "Onartuta", "iraungitzeData": "2026-12-31T23:59:59Z" } }]"

2.0.1 bertsioan, erantzunak testuinguru gehiago dauka, hala nolaidTokenmota eta erabiltzaile-interfazearen informazio gehigarria.

2.0.1 Baimen-erantzuna:"json [3, "987654", { "idTokenInfo": { "status": "Onartuta", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "Ongi etorri berriro, John! Zure saldoa 45,00 $ da" } } }]"

A.2 Bihotz-taupadak eta konexioen kudeaketa

OCPP 2.0.1-ek estazioak "bizirik" dagoela frogatzeko modua optimizatzen du. 1.6J-tan, baldin etaBihotz-taupadakhuts egiten bazuen, estazioak askotan berriro saiatzen jarraituko zuen. 2.0.1 bertsioan, estazioak erabil dezakeJakinaraziGertaeramekanismo bat bigarren mailako backend batekin duen konexioa galdu dela jakinarazteko, nagusiarekin taupada bat mantenduz.

A.3 Metadatuen taula zehatza

Ondorioa

OCPP 1.6J-tik 2.0.1-erako trantsizioa ez da software eguneratze soil bat; mugikortasun elektrikoaren ekosistemaren funtsezko bilakaera da. Operadore komertzialentzat, 1.6J-k iragan fidagarria adierazten du, eta 2.0.1-ek, berriz, etorkizun eskalagarria, segurua eta adimentsua.

2.0.1 aukeratzea gaur egun iraupenean inbertitzea da. Zure hardwarea hurrengo belaunaldiko ibilgailu elektrikoekin bateragarria izango dela ziurtatzen du, zibersegurtasun araudi zorrotzagoekin bat etorriko dela eta V2G eta sare adimendunen integrazioaren aukera errentagarrietarako prest egongo dela. Merkatua finkatzen den heinean, protokolo pila sendoenak eta malguenak dituzten operadoreak izango dira eragile nagusi.

11. kapitulua: Sakonera: Mezu-fluxuaren azterketa eta sekuentzia-diagramak

Kapitulu honetan, EVSE eta CSMS arteko interakzio-sekuentziak aztertuko ditugu 1.6J eta 2.0.1 arteko funtzionamendu-desberdintasunak erakusteko.

11.1 Abio eta konfigurazio sekuentzia

Kargagailu bat lehen aldiz sarera konektatzen denean, bere burua identifikatu eta bere konfigurazioa sinkronizatu behar du.

OCPP 1.6J-ko emaria:

1. WebSocket konexioa80 edo 443 portuan ezarrita.
2. Abio-jakinarazpena: Estazioak saltzailea, modeloa eta serie-zenbakia bidaltzen ditu.
3. Lortu konfigurazioaCSMS-k giltza guztiei uneko egoera egiaztatzeko eskatzen die.
4. Konfigurazioa aldatuCSMS-k gako espezifikoak eguneratzen ditu (adibidez,Bihotz-taupada tartea).
5. Egoera-jakinarazpena: Estazioak “Eskuragarri” dagoela jakinarazi du.

OCPP 2.0.1 Fluxua:

1. TLS esku-emate segurua: Derrigorrezko ziurtagirien trukea.
2. Abio-jakinarazpena: Barne hartzen dituarrazoia(adibidez,Piztu).
3. LortuOinarrizkoTxostenaGako guztiak eskatu beharrean, CSMS-k "Oinarrizko Txosten" bat eskatzen du, Gailu Ereduaren hierarkia osoa ematen duena.
4. Aldagaiak ezarriCSMS-k aldagaiak eguneratzen ditu. Kontuan izan 2.0.1 bertsioak eguneratze atomikoak ahalbidetzen dituela —mezu bakarrean aldagai anitz ezarriz eta guztiek arrakasta dutela edo batek ere ez duela arrakasta izango ziurtatuz—.
5. JakinaraziGertaera: Estazioak hasierako osagaien egoeraren berri ematen du.

11.2 Karga Adimendunaren Negoziazioa

Kargatze adimenduna da 2.0.1-ek benetan distira egiten duen tokia, batez ere kargatzeko profil anitz kudeatzerakoan.

1.6J-tan, CSMS-k bidaltzen duEzarri kargatzeko profilapila maila eta ordutegi bat definitzen dituena. Estazio batek konektore anitz baditu, profilaren kudeaketa anbiguoa izan ohi da.

2.0.1ean,Ezarri kargatzeko profilaesplizituki lotuta dago batikargatzeko profilaHelburua.

• Kargatzeko Estazioko ProfilaMax: Estazio osoaren sarrera mugatzen du.
• TXDefaultProfile: Transakzio berri ororen lehenetsitako balioa.
• TXProfile: Transakzio martxan dagoen bati dagokio.

Gainera, 2.0.1 bertsioak onartzen duLortuKargatzekoPilarenMailamezua, CSMSri aukera emanez zein profil dauden aktibo eta EVSEren barne-planifikatzaileak nola lehenesten dituen ikusteko.

11.3 Urruneko Abiaraztea eta Kontrola

Urruneko komandoak, adibidezUrrunetikHasierakoTransakzioa(1,6J) ordezkatu diraEskaeraHasierakoTransakzioa(2.0.1). Desberdintasun nagusia zama erabilgarrian dago. 2.0.1ean, CSMSak honako hauek izan ditzake:kargatzeko profilazuzenean abiarazteko eskaeran. Horrek esan nahi du autoak berehala has daitekeela kargatzen potentzia-maila egokian, bigarren mezu baten zain egon gabe, latentzia murriztuz eta sarearen egonkortasuna hobetuz.

12. kapitulua: JSON eskema eta eremuen maila baxuko konparaketak

Garatzaile eta sistema integratzaileentzat, eskema aldaketak dira migrazioaren zatirik lantsuena.

12.1 Mota zenbatuak (Enumak)

OCPP 2.0.1-ek Enum estandarizatuen kopurua asko zabaltzen du, 1.6J inplementazioetan zeuden "Pertsonalizatutako" egoera-kodeen beharra murriztuz.

• Arrazoi Enums: Zaintza-txakurra, Programatutako Berrezarpena, Urrunetik Berrezarri, Energia-galera.
• Egoera-zenbaketak: Okupatuta, Erreserbatuta, Ez dago eskuragarri, Akatsduna. 2.0.1 gehigarriakEskuragarri, Okupatuta, Erreserbatuta, Ez dago eskuragarri, Akatsdunabaina xehetasun gehiagorako azpi-egoerekin.

12.2 Datu motak eta unitateak

OCPP 2.0.1-ek unitate estandarren (SI) erabilera formalizatzen du. 1.6J-k batzuetan hamartar zehaztasuna definitu gabe uzten zuen bitartean, 2.0.1-ek erabiltzen duhamartarrapotentzia eta energia balioen motak, saltzaile desberdinen hardwarearen fakturazio koherentea bermatuz.

13. kapitulua: Kasu-azterketa: CPO migrazio globala 1.6J-tik 2.0.1-ra

Ikus dezagun “MegaCharge”-ren eszenatoki hipotetiko bat, 10.000 karga-puntu dituen CPO bat.

13.1 1. fasea: Auditoria

MegaCharge-k aurkitu zuen bere 1.6J flotaren % 40k ez zuela TLS 1.2 onartzen. Horrek esan nahi zuen kargagailu horiek ez zirela gai etorkizuneko gobernu-kontratuetarako.

13.2 2. fasea: CSMSren eguneratzea

CSMS berri bat eraiki beharrean, MegaCharge-k "OCPP itzulpen geruza" bat ezarri zuen. Geruza honek 1.6J konexioak kudeatzen zituen hardware zaharrerako eta 2.0.1 hardware berrirako, baina API bateratu bat erakutsi zion mugikorretarako aplikaziora eta fakturazio motorrera.

13.3 3. fasea: Hardwarearen ordezkapena

Trafiko handiko guneetarako, MegaCharge-k 1.6J-ko kargagailuak 2.0.1-ekin bateragarriak diren DC kargagailu azkarrekin ordezkatu zituen. Emaitza "Hasiera huts egin" saioetan % 15eko murrizketa izan zen, batez ere bateria sendoagoa erabiltzeagatik.TransakzioGertaera2.0.1 bertsioan maneiatzea.

13.4 ROI azterketa

Hasierako inbertsioa 2 milioi dolarrekoa izan zen. Hala ere, mantentze-lanetarako deialdi murriztuek (Gailu Modeloaren diagnostikoei esker) urtean 400.000 dolar aurreztu zituzten. Gainera, V2G maiztasun-erantzun merkatuetan parte hartzeko gaitasunak urteko 200.000 dolar gehigarri sortu zituen. Itzultze-epea 3,3 urtekoa izan zen gutxi gorabehera.

14. kapitulua: Eroslearen kontrol-zerrenda osoa OCPP 2.0.1 erosketarako

Hardware edo software berria ebaluatzerakoan, erabili kontrol-zerrenda hau benetako betetzea ziurtatzeko:

14.1 Hardwarearen (EVSE) eskakizunak

• [ ]Segurtasun Profila 3 LaguntzaBezeroaren aldeko ziurtagirien kudeaketa onartzen al du?
• [ ]Nukleo bikoitzeko prozesadoreaBa al dago nahikoa tarte TLS enkriptaziorako eta JSON parserako?
• [ ]Elementu Segurua (SE)Plakak badu giltzak gordetzeko konfiantzazko hardware errorik?
• [ ]ISO 15118-2/20rako prestKontrolatzaileak PnC-rako beharrezkoa den goi-mailako komunikazioa kudeatu al dezake?
• [ ]Pantaila gaitasunaHardwareak prezio/egoera informazioa OCPP bidez erakustea onartzen al du?Datuen transferentziaedo bertako mezuak?

14.2 Softwarearen (CSMS) eskakizunak

• [ ]Gailuaren ereduaren bistaratzeaKargagailuaren ikuspegi hierarkikoa erakuts al dezake aginte-panelean?
• [ ]Ziurtagiri-agintaritzaren (CA) integrazioaCSMSak ziurtagiriak automatikoki jaulki eta txandakatu al ditzake?
• [ ]Transakzioen bateratzeaNola kudeatzen ditu sistemak 1.6J-ko kargagailu zaharretatik datozen transakzio “zintzilikatuak”?
• [ ]Kargatzeko motor adimenduna2.0.1 bertsioaren pila-mailako logika aurreratua onartzen al du?
• [ ]EskalagarritasunaWebSocket kudeatzaileak 50.000 TLS konexio iraunkor baino gehiago aldi berean kudea ditzake?

15. kapitulua: OCPP inplementazio arazo ohikoenak konpontzea

Estandar bat izan arren, inplementazioak aldatu egiten dira. Hona hemen ohikoenak diren "akatsak".

15.1 WebSocket denbora-mugak

Sare-suebaki askok TCP konexio inaktiboetan ixten dituzte. Baldin eta...Bihotz-taupada tarteaaltuegia bada, kargagailua deskonektatuta egon daiteke.

• IrtenbideaZiurtatuBihotz-taupada tarteasuebakiaren denbora-muga baino txikiagoa da (normalean 60-120 segundo).

15.2 Ziurtagiri-katearen arazoak

2.0.1 bertsioan ohikoa den akats bat "Ziurtagiri fidagarria ez" errorea da. Hau normalean kargagailuak CSMSren erroko CA instalatuta ez duenean gertatzen da.

• IrtenbideaErabiliInstalazio Ziurtagiriakonfiantza-katea osoa dela ziurtatzeko, martxan jartzean mezua.

15.3 JSON kargaren tamaina

2.0.1 mezu batzuk (adibidezLortuOinarrizkoTxostena) oso handia izan daiteke. Kargagailuaren bufferra txikiegia bada, mezua galduko du.

• Irtenbidea: EgiaztatuMezuaren Gehienezko Tamainaaldagai bat Gailu Modeloan eta ziurtatu CSMSak muga hau errespetatzen duela.

16. kapitulua: Eskualdeko araudi-paisaiak eta protokolo-aginduak

OCPP 2.0.1erako jauzia ez dator teknologiak bakarrik bultzatuta; gero eta gehiago lege kontua da.

16.1 Europar Batasuna (AFIR)

EBko Erregai Alternatiboen Azpiegituren Erregelamenduak (AFIR) prezioen gardentasuna eta interoperabilitatea agintzen ditu. OCPP 2.0.1 berariaz aipatzen ez duen arren, "datuen denbora errealeko partekatzea" eta "karga adimenduna" eskakizunak 2.0.1 bihurtzen du azpiegitura publiko berrietarako estandar bideragarri bakarra.

16.2 Ipar Amerika (NEVI)

Estatu Batuetan, Ibilgailu Elektrikoen Azpiegitura Nazionalaren (NEVI) formula programak kargagailuak “elkarreragingarriak” izatea eskatzen du. Kalifornia bezalako estatuak are gehiago ari dira egiten, Kaliforniako Energia Batzordeak (CEC) ISO 15118 euskarria bultzatzen baitu, eta hori, aipatu dugun bezala, OCPP 2.0.1 bidez ezartzen da hobekien.

16.3 Txina eta Asia-Pazifikoa

Txinak bere estandarrak baditu ere (GB/T), esportaziora bideratutako fabrikatzaileek inbertsio handiak egin dituzte OCPP 2.0.1-en. Australia eta Singapur bezalako merkatuetan, kargatzeko sare publikoetarako gobernuaren lizitazioek ia esklusiboki OCPP 2.0.1 zehazten dute 3. Segurtasun Profilarekin.

17. kapitulua: Inplementazio-kode zatiak: xehetasunak

Garatzaileei laguntzeko, 2.0.1 zeregin konplexuetarako JSON irudikapen kontzeptualak eskaintzen ditugu.

17.1 Ziurtagirien errotazio-fluxua

Ziurtagiri bat iraungitzear dagoenean, CSMSak errotazio bat abiarazi behar du.

1. CSMSk bidaltzen duZiurtagiriaSinatua:"json [2, "CERT-01", "CertificateSigned", { "certificateChain": "-----ZIURTAGIRIAREN HASIERA-----\n...\n------ZIURTAGIRIAREN AMAIERA-----", "certificateType": "V2G" }]"

2. Estazioak erantzuten duOnartuta:"json [3, "CERT-01", { "egoera": "Onartuta" }]"

3. Estazioak bidaltzen duSegurtasun Gertaeren Jakinarazpena:"json [2, "EVT-99", "SegurtasunGertaerenJakinarazpena", { "mota": "ZiurtagiriaBilatua", "denbora-zigilua": "2026-08-09T10:00:00Z" }]"

17.2 Sare elektrikoari erantzuten dion kargatze-profil bat ezartzea

Imajinatu sareko operadoreak sare osoko potentzia murriztu behar duela.

CSMSk bidaltzen duEzarri kargatzeko profila:"json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "chargingProfileKind": "Absolutua", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limite": 11000 }, { "startPeriod": 3600, "limite": 22000 } ] } } }]"

18. kapitulua: OCPP 2.0.1 terminoen glosario osoa

Interesdun guztientzat argitasuna bermatzeko, glosario zabaldua eskaintzen dugu.

• CSMS (Kargatzeko Estazioen Kudeaketa Sistema)Kargagailuak kontrolatzen dituen hodeiko plataforma.
• EVSE (Ibilgailu Elektrikoen Hornidura Ekipamendua): Kargatzeko estazio fisikoa.
• OCPP (Kargatzeko Puntu Irekiaren Protokoloa): Hitz egiten duten hizkuntza.
• OCA (Karga Irekiko Aliantza): Hizkuntza idazten duen erakundea.
• ISO 15118: Autoaren eta kargagailuaren arteko protokoloa.
• PnC (Entxufatu eta Kargatu)ISO 15118 eta OCPP 2.0.1 arauek gaitzen duten erabiltzailearen esperientzia.
• V2G (Ibilgailutik Sare Elektrikora): Autoaren energia sarera itzultzea.
• V2X (Ibilgailutik Denarako)V2G, V2H eta V2B izendapenen termino orokorra.
• TLS (Garraio Geruzaren Segurtasuna): Datuak seguru mantentzen dituen enkriptazioa.
• PKI (Giltza Publikoko Azpiegitura): Segurtasunerako erabiltzen diren ziurtagiri digitalen sistema.
• JSON (JavaScript Objektuen Notazioa): Mezuen formatua.
• WebSocketMezuak zeharkatzen dituen konexio "hodi" iraunkorra.
• Gailuaren modeloa2.0.1-ek hardwarea deskribatzen duen modu hierarkikoak.
• OsagaiaHardwarearen zati bat (adibidez, konektorea).
• AldagaiaOsagai baten propietatea (adibidez, Egoera).
• AtributuaAldagai bati buruzko metadatuak (adibidez, Balioa, Aldakortasuna).
• TransakzioGertaera2.0.1 bertsioko saio-datu guztien mezu bateratua.
• Bihotz-taupadak: «Bizirik nago» aldizkako seinalea.
• Abio-jakinarazpena«Kaixo, hemen nago» seinalea kargagailua martxan jartzen denean.
• Datuen transferentziaSaltzaile espezifikoen luzapenetarako mezu orokorra (kontuz erabili!).

Azken gogoetak: Protokolo anitzeko aroan nabigatzen

Erosle edo operadore gisa, ondoriorik garrantzitsuena da sartzen ari garela...protokolo anitzeko aroaHurrengo 3-5 urteetan, 1,6 J eta 2,0,1 elkarrekin egongo dira. Hala ere, oreka azkar aldatzen ari da.

Gaur OCPP 2.0.1 aukeratuz gero, ez duzu protokolo bat erosten bakarrik; asegurua erosten ari zara. Zure sarea auto berrietara, lege berrietara eta diru-sarrera iturri berrietara egokitu daitekeela ziurtatzen ari zara. 2.0.1-en konplexutasuna aurrerapenaren prezioa da: funtzionamendu-denbora hobetuaren, arriskuaren murrizketaren eta bezeroarentzako esperientzia hobeagoaren bidez ordaintzen den prezioa.

Karga komertziala ez da jada industria nitxo bat; etorkizuneko garraio sistemaren bizkarrezurra da. Eraiki bizkarrezurra ahalik eta oinarri sendoenaren gainean: OCPP 2.0.1.

19. kapitulua: OCPP 2.0.1erako garatzea: Software ingeniarientzako jardunbide egokiak

1.6J kode-base batetik 2.0.1era igarotzea ez da berregituraketa bat; berridazketa bat da. Garatzaileek beste eredu mental bat hartu behar dute.

19.1 Asinkronismoa onartzea

WebSocket-ak berez asinkronoak diren arren, 2.0.1-en konplexutasunak eskaera bakar batek (adibidezLortuOinarrizkoTxostena) hainbat segundo behar izan ditzake baliabide mugatuko EVSE batean prozesatzeko. CSMS garatzaileek denbora-muga eta berriro saiatzeko logika sendoa inplementatu behar dute, hardware saltzaile desberdinen prozesatzeko abiadura desberdinak kontuan hartzen dituena.

19.2 JSON analisi eraginkorra

JSON parserrak CPU asko kontsumitu dezake. EVSE firmwarearentzat, garatzaileek erreka-oinarritutako parserrak erabili beharko lituzkete, RAM memorian kargatu beharrean. Hau bereziki garrantzitsua da...JakinaraziGertaeramezuak, ehunka aldagai eguneratze izan ditzaketenak fotograma bakarrean.

19.3 Egoera-makinaren kudeaketa

2.0.1 bertsioko transakzio baten egoera-makina 1.6J bertsiokoa baino zurrunagoa da. Garatzaileek trantsizio-arauak zorrotz jarraitu behar dituzte.TransakzioGertaeraAdibidez, ezin duzu bidaliAmaitu dagertaera bat lehenago bidali gabeHasi daekitaldi zehatz horretarakotransakzio IDa.

20. kapitulua: Probak, baliozkotzea eta OCPP betetze-proba tresna (OCTT)

Elkarreragingarritasuna da OCPP-ren promesa, baina proba zorrotzen bidez bakarrik lortzen da.

20.1 OCA Ziurtagiriaren Zeregina

Open Charge Alliance-k ziurtagiri programa bat eskaintzen du. Erosleek “OCPP 2.0.1 Certified” etiketa bilatu beharko lukete. Ziurtagiri honek inplementazioak derrigorrezko profil guztiak hartzen dituzten proba automatizatu multzo bat gainditu duela ziurtatzen du.

20.2 OCTT erabiliz

OCPP Compliance Test Tool (OCTT) da probak egiteko urrezko estandarra. CSMS bat eta EVSE bat simulatzen ditu.

• EVSE fabrikatzaileentzatErabili OCTT zure estazioak "bide zoriontsu" eszenatokiak eta ertzeko kasuak (firmware eguneratze batean sareko erorketak bezala) kudeatzen dituela egiaztatzeko.
• CSMS hornitzaileentzatErabili OCTT zure backend-ak mezuen barietate handia eta 2.0.1 bertsioaren segurtasun-eskakizun zorrotzak kudeatu ditzakeela ziurtatzeko.

20.3 Eremu-probak eta interoperabilitate-jaialdiak

Proba automatizatuez gain, OCAk "Plugfest"ak antolatzen ditu, non saltzaileek beren hardwarea eta softwarea ekartzen dituzten elkarren aurka probatzeko benetako munduko egoeretan. Hemen detektatu eta konpontzen dira akats sotilenak —ziurtagirien bateraezintasuna edo JSON formatuaren arteko desberdintasun txikiak, adibidez—.

21. kapitulua: Taula konparatibo sakona: OCPP 2.0.1-en 60 ekintza baino gehiago

Erreferentzia osoa emateko, 2.0.1 bertsioaren mezu nagusiak sailkatu eta 1.6J-koekin alderatu ditugu.

21.1 Hornidura eta konfigurazioa

21.2 Transakzioen kudeaketa

21.3 Segurtasun eta Firmware Kudeaketa

21.4 Zer esan nahi du taulak zure sarearentzat

Taulak puntu bat argi uzten du: OCPP 2.0.1 ez da 1.6J-ren izen aldaketa kosmetiko bat. Mezu-familia berriak —motakatutako aldagaiak, gertaeretan oinarritutako transakzioak eta ziurtagirien kudeaketa— Plug & Charge, kargatze adimenduna eta araudi-txostenak egiteko beharrezkoak diren iturgintza dira. 1.6J-n bakarrik hitz egiten duen kargagailu bat pasabide batekin hornitu daiteke, baina 1.6J-n bakarrik hitz egiten duen CSMS batek ezin du eman erregulatzaileek eta automobilgileek gero eta gehiago eskatzen duten segurtasun-eredua. Hardwarea ebaluatzerakoan, "2.0.1-prest" egoteak firmwarea gaur bidaltzen ari dela esan nahi du, ez datorren urterako programatuta. Eta OCPP 2.0.1 JSON-over-WebSocket-en exekutatzen denez, 1.6J-ren SOAP garraioaren ordez, mezu-fluxuak arinagoak eta askoz errazagoak dira arazteko —abantaila praktikoa zure IT taldeak lehen egunetik sentituko duena—.

22. kapitulua: Ondorioa: Berritze erabakia hartzea

Operadore komertzial batentzat, jarraibide praktikoak argiak dira:

• Inplementazio berriek OCPP 2.0.1 bertsioa lehenespenez erabili beharko lukete.Segurtasun eredua, ziurtagirien kudeaketa eta ISO 15118 integrazioa 2026ko araudi ingurunerako aurrebaldintzak dira.
• Dauden 1.6J-ko flotak ez daude hondatuta.Kudeatutako atebideek eta protokolo bikoitzeko CSMS plataformek zubi-lana egiten dute 2.0.1 hardware natiboa pixkanaka txertatzen duzun bitartean.
• Fidatu aurretik probatu.Erabili OCTT, plugfestak eta fase bidezko inplementazioak — elkarreragingarritasuna frogatuta dago eremuan, ez da datu-orritik ondorioztatzen.
• Eskatu migrazio-bide bat idatziz.Zure kargagailu saltzaileak 1.6J-tik 2.0.1-erako firmware bide-orri bat argitaratu beharko luke datekin, ez promesa lausoekin.

Ekintzarako deia: hitz egin MIDA Power-ekin zure protokolo-estrategiari buruz

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.