OCPP 1.6J:n ja 2.0.1:n strateginen vertailu kaupallisille latausasemille

OCPP 1.6J:n ja 2.0.1:n lopullinen strateginen vertailu globaaleille kaupallisille latausasemien operaattoreille: Verkon skaalautuvuuden hallinta, edistynyt kyberturvallisuus, ISO 15118 -integraatio ja pitkän aikavälin infrastruktuurin tulevaisuuden varmistaminen kestävää sähköautojen kasvua varten

Tiivistelmä

Sähköajoneuvojen latausmarkkinat ovat läpikäymässä mullistavaa muutosta. Maailmanlaajuisen käyttöönoton kiihtyessä sähköajoneuvojen latauslaitteiden (EVSE) ja latausasemien hallintajärjestelmien (CSMS) välistä vuorovaikutusta säätelevät viestintäprotokollat ​​ovat nousseet kaupallisten latausoperaattoreiden (CPO) teknisen strategian keskipisteeksi. Open Charge Alliancen (OCA) ylläpitämä Open Charge Point Protocol (OCPP) on kehittynyt yksinkertaisesta viestintäkehyksestä hienostuneeksi, turvalliseksi ja erittäin skaalautuvaksi standardiksi.

Tämä opas tarjoaa kattavan teknisen analyysin siirtymisestä OCPP 1.6J:stä OCPP 2.0.1:een. Tutkimme arkkitehtuurieroja, tietoturvaparannuksia, laitehallinnan parannuksia ja ISO 15118 -integraation kriittistä roolia. Ostajille ja operaattoreille tämä artikkeli toimii lopullisena lähteenä tietoon perustuvien hankinta- ja siirtymäpäätösten tekemiseen nopeasti kypsyvillä markkinoilla.

Luku 1: Sähköautojen latausstandardien kehitys: historiallinen konteksti

Open Charge Point Protocol (OCPP) syntyi yhteentoimivuuden tarpeesta. Sähköautojen latauksen alkuaikoina laitevalmistajat ja ohjelmistotoimittajat käyttivät omia protokolliaan, mikä loi "aidattuja puutarhoja", jotka tukahduttivat kilpailun ja innovaatiot. OCPP 1.2:n ja 1.5:n käyttöönotto loi pohjan, mutta vasta OCPP 1.6 todella yhdisti alan.

1.1 OCPP 1.6J:n dominointi

Vuonna 2015 julkaistu OCPP 1.6 esitteli JSON over WebSockets (1.6J) -toteutuksen. Tämä siirtyminen pois SOAP-pohjaisesta viestinnästä vähensi merkittävästi kehittäjien yleiskustannuksia ja yksinkertaisti toteutusta. Se esitteli ominaisuuksia, kuten älykkään latauksen ja lisätilailmoitukset, mikä teki siitä alan standardin lähes vuosikymmeneksi.

1.2 OCPP 2.0.1:n synty

1.6J:n menestyksestä huolimatta alan kasvu paljasti sen rajoitukset. Tietoturvaongelmat, laitteenhallinnan monimutkaisuus ja natiivin tuen puute edistyneelle verkkointegraatiolle (V2G) johtivat OCPP 2.0:n ja myöhemmin parannetun OCPP 2.0.1:n (julkaistu vuonna 2020) kehittämiseen. OCPP 2.0.1 ei ole pelkkä päivitys; se on täydellinen uudelleensuunnittelu, jonka tarkoituksena on tukea seuraavan sukupolven suuritehoisia, älykkäitä ja turvallisia latausverkkoja.

Luku 2: Taustalla olevat viestintäparadigmat: JSON, WebSockets ja kehysrakenteet

Näiden protokollien erojen ymmärtämiseksi on tarkasteltava matalan tason viestintää. Molemmat protokollat ​​käyttävät JSONia WebSocketsin kautta, mutta viestien rakenne ja käsittely eroavat toisistaan ​​merkittävästi.

2.1 WebSocket-kerros

Molemmat versiot käyttävät pysyviä WebSocket-yhteyksiä, jotka mahdollistavat kaksisuuntaisen tiedonsiirron. Tämä on kriittistä reaaliaikaisille toiminnoille, kuten lataussession pysäyttämiselle mobiilisovelluksesta tai välittömien vikailmoitusten vastaanottamiselle.

2.2 Viestikehyksen erittely

Tyypillinen OCPP-viesti koostuu viestityypin tunnuksesta, yksilöllisestä viestitunnuksesta, toiminnon nimestä ja hyötykuormasta.

OCPP 1.6J -kehysesimerkki (BootNotification)

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

OCPP 2.0.1 -kehysesimerkki (BootNotification)

”json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`Huomaa lisääntynyt tarkkuus versiossa 2.0.1.reason`-kentän avulla CSMS ymmärtää, johtuiko käynnistys uudelleenkäynnistyksestä, käynnistyksestä vai valvontatoiminnon laukaisimesta, mikä mahdollistaa paremman diagnostiikkalogiikan.

Luku 3: Arkkitehtuuriparadigman muutos: Laitemalli

Merkittävin tekninen muutos OCPP 2.0.1:ssä on seuraavan käyttöönotto:Laitemalli.

3.1 1.6J-konfiguraatioavainten rajoitukset

OCPP 1.6J:ssä laitteistokokoonpanoa hallittiin "määritysavainten" luettelon avulla (esim.Sydämenlyöntiväli, Yhteyden aikakatkaisu). Latureiden monimutkaistuessa (moniliittimet, integroidut tehomoduulit, monimutkaiset jäähdytysjärjestelmät) tästä tasaisesta luettelosta tuli hallitsematon. Aseman fyysisen hierarkian kuvaamiseen ei ollut standardoitua tapaa.

3.2 Laitemallin 2.0.1-lähestymistapa

OCPP 2.0.1 esittelee hierarkkisen mallin, joka koostuu seuraavista:KomponentitjaMuuttujatKomponentti voi olla ”Ohjain”, ”Liitin” tai ”Virtamoduuli”. Jokaisella komponentilla on muuttujia, jotka edustavat sen tilaa tai kokoonpanoa (esim.Lämpötila, Jännite, Maksimivirta).

• KomponenttiLatausaseman fyysinen tai looginen osa.
• Muuttuja: Kyseisen komponentin tietty ominaisuus.
• OminaisuudetMuuttujaa kuvaava metatieto (yksikkö, alue, käyttötapa).

Tämä mahdollistaa standardoidun valvonnan. Käyttäjä voi nyt kysellä tietyn tehomoduulin lämpötilaa standardoidun polun kautta sen sijaan, että hän turvautuisi toimittajakohtaisiin suljetun järjestelmän avaimiin.

Luku 4: Kyberturvallisuus: "Parhaasta mahdollisesta" -periaatteesta pakolliseen TLS-salaukseen

Sähköautojen latauksen alkuaikoina turvallisuus oli usein jälkikäteen mietitty asia. OCPP 1.6J tarjosi turvallisuusprofiileja, mutta niiden toteutus oli epäjohdonmukainen eri toimittajien välillä.

4.1 Suojausprofiilit versiossa 1.6J

OCPP 1.6J määritteli kolme suojausprofiilia:

1. VakuudetonSelkokielinen HTTP/WebSockets.
2. PerustodennusTLS käyttäjätunnuksella/salasanalla.
3. TodistepohjainenTLS asiakaspuolen varmenteilla.

Ongelmana oli, että monet laturit pysyivät profiilissa 1, mikä teki niistä alttiita välikäsihyökkäyksille (MITM) ja luvattomalle käytölle.

4.2 Version 2.0.1 koventunut asenne

OCPP 2.0.1 edellyttää turvallista viestintää. Se integroi edistyneet tietoturvaominaisuudet natiivisti:

• Turvalliset laiteohjelmistopäivityksetLaiteohjelmistokuvien pakollinen allekirjoittaminen ja varmennus.
• TietoturvalokiYksityiskohtaiset lokit tietoturvaan liittyvistä tapahtumista (esim. epäonnistuneet kirjautumisyritykset, varmenteen vanheneminen).
• Varmenteiden hallintaStandardoidut viestit kierrätetyille ja päivitetyille varmenteille (CSMS:n tai aseman johtamat).
• TLS 1.2/1.3Tuki uusimmille salausstandardeille.

Kaupallisille operaattoreille tämä vähentää massiivisten verkkokompromissien riskiä ja varmistaa IoT-laitteiden uusien kyberturvallisuusmääräysten noudattamisen.

Luku 5: ISO 15118 -integraatio: Plug & Charge ja V2G

Sähköautojen latauksen tulevaisuus ei koske pelkästään elektronien liikuttamista; kyse on älykkäästä tiedon ja energian vaihdosta. ISO 15118 on kansainvälinen standardi ajoneuvosta verkkoon (V2G) -viestinnälle, ja sen integrointi OCPP:n kanssa on 2.0.1:n määrittelevä ominaisuus.

5.1 Plug & Charge -tekniikan monimutkaisuus

Plug & Charge (PnC) -tekniikka mahdollistaa kuljettajan yksinkertaisesti kytkeä ajoneuvon pistorasiaan ja aloittaa latauksen ilman sovellusta tai RFID-korttia. Tämä vaatii monimutkaisen julkisen avaimen infrastruktuurin (PKI), johon osallistuvat ajoneuvo, laturi, käyttäjä ja tiedonvälityskeskus.

OCPP 1.6J:ssä PnC-tukea ei ollut perusprotokollassa. Valmistajien piti toteuttaa mukautettuja laajennuksia, mikä johti pirstoutumiseen. OCPP 2.0.1 tarjoaa PnC:n "liitännät" tukemalla:

• Varmenteen asennusSopimustodistusten välittäminen CSMS:stä sähkölaitteeseen EVSE:n kautta.
• ValtuutusKäyttämällä ajoneuvon sertifikaatista johdettua e-Mobility ID:tä (eMAID).
• Salattu viestintä: Auton ja sähköverkon välillä välitettävien arkaluonteisten laskutustietojen suojauksen varmistaminen.

5.2 Älykäs lataus ja kuorman tasapainotus

Vaikka 1.6J tuki perusälykästä latausta (lähettiAseta latausprofiili), 2.0.1 nostaa tätä tasoa. Se mahdollistaa:

• Ulkoisen signaalin integrointiReaaliaikainen vaste verkon taajuus- tai tukkuhintasignaaleihin.
• Dynaaminen kuormituksen hallintaTarkempi virranjakelun hallinta satoja liittimiä sisältävässä kohteessa.
• Ajoneuvosta verkkoon (V2G)Versio 2.0.1 sisältää tarvittavat datakentät kaksisuuntaisen energiankulun tukemiseksi, jolloin sähköajoneuvot voivat toimia hajautettuina energiaresursseina (DER) sähköverkossa.

5.3 Käyttöliittymän/käyttökokemuksen parannukset

OCPP 2.0.1 tukee tietojen näyttämistä suoraan laturin näytöllä tai ajoneuvon kojelaudassa, kuten:

• Reaaliaikainen hinnoittelu paikallisessa valuutassa.
• Arvioitu aika 80 %:n lataustilan (SoC) saavuttamiseen.
• Tarkemmat kuittitiedot valmistuttua.

Luku 6: Edistynyt laitehallinta ja -valvonta

Laturitoimittajalle laturin hinta ei ole pelkkä ostohinta, vaan se on kokonaiskustannukset (TCO). Huolto ja seisokkiajat ovat suurimpia kannattavuuden tappajia. OCPP 2.0.1 ratkaisee tämän erinomaisten valvontaominaisuuksien avulla.

6.1 Tapahtumapohjainen raportointi

1.6J-mallissa CSMS:n piti yleensä kysellä laturin tilaa tai odottaaTilailmoitusVersiossa 2.0.1Tapahtumien seurantaJärjestelmä sallii CSMS:n asettaa kynnysarvoja. Esimerkiksi: ”Ilmoita vain, jos sisälämpötila ylittää 70 °C” tai ”Ilmoita, jos tulojännite laskee alle 200 V.” Tämä vähentää verkkoliikennettä ja mahdollistaa ennakoivan huollon.

6.2 Transaktioiden käsittely: TransactionEvent

Yksi OCPP 1.6J:n kritisoiduimmista puolista oli sen transaktioiden käsittely. Istunto, johon liittyiAloita tapahtumajaStopTransactionviestejä, mutta jos verkkoyhteys katkesi, CSMS:llä oli usein vaikeuksia täsmäyttää laskutustietoja.

OCPP 2.0.1 korvaa nämä yhdellä, vankallaTransaktiotapahtumaviesti. Tätä viestiä käytetään raportoimaan kaikki tapahtuman elinkaaren vaiheet (aloitettu, päivitetty, päättynyt). Se sisältää yksilöllisentapahtumatunnusjoka säilyy, vaikka laturi käynnistyisi uudelleen, varmistaen, ettei latausdataa – eikä siten myöskään tuloja – menetetä.

6.3 Parannettu diagnostiikka ja vianmääritys

TheGetLogjaDiagnostiikkaTilailmoitusVersiossa 2.0.1 viestit ovat jäsennellympiä. Tietoturvavastaavat voivat pyytää tietyntyyppisiä lokeja (tietoturva, diagnostiikka, käyttäjä) ja määrittää aikavälit. Tämä mahdollistaa etätukitiimien ratkaista ongelmia lähettämättä teknikkoa paikan päälle, mikä alentaa merkittävästi käyttökustannuksia.

Luku 7: Laiteohjelmiston päivitysmekanismit: Luotettavuus ja palautukset

Laiteohjelmistopäivitykset ovat kehittyvän laitteiston elinehto, mutta epäonnistunut päivitys voi rikkoa laturin.

7.1 1.6J-päivitysprosessi

1,6 joulen moottorissaPäivitä laiteohjelmistoKomento oli suhteellisen yksinkertainen. Laturi latasi kuvan ja yritti asentaa sen. Monivaiheisille päivityksille tai vahvistetuille palautuksille ei ollut standardoitua mekanismia.

7.2 Monivaiheinen päivitys 2.0.1

OCPP 2.0.1 esittelee kehittyneemmän laiteohjelmistopäivitysten elinkaaren:

1. LataaLaturi hakee kuvan ja tarkistaa sen tarkistussumman/allekirjoituksen.
2. AsennusPäivitys otetaan käyttöön toissijaisessa osiossa.
3. VahvistusJärjestelmä tarkistaa, käynnistyykö uusi laiteohjelmisto oikein.
4. AktivointiEnsisijainen osio on vaihdettu.

Jos jokin vaihe epäonnistuu, protokolla määrittää, miten laturin tulisi palata edelliseen vakaaseen versioon ja raportoida tietty vikakoodi CSMS:lle. Tästä luotettavuustasosta ei voida tinkiä laajamittaisissa kaupallisissa käyttöönotoissa.

7.3 Allekirjoituksen varmennus

Jotta pahantahtoiset toimijat eivät voisi ladata vaarannettua laiteohjelmistoa, versio 2.0.1 edellyttää digitaalisten allekirjoitusten käyttöä. Laturi kieltäytyy suorittamasta koodia, jota ei ole allekirjoitettu valmistajan yksityisellä avaimella, mikä lisää kriittisen suojakerroksen laitteistotason hakkerointeja vastaan.

Luku 8: Tietosuoja, määräystenmukaisuus ja GDPR

Sähköautojen lataamisen yleistyessä jokapäiväiseksi hyödykkeeksi, syntyvän henkilötiedon määrä on valtava. Yksi latauskerta voi yhdistää käyttäjän henkilöllisyyden, ajoneuvon sijainnin, matkustustottumukset ja taloudelliset tiedot.

8.1 Henkilötiedot (PII) OCPP:ssä

Euroopan yleisen tietosuoja-asetuksen (GDPR) ja Kalifornian vastaavien lakien, kuten CCPA:n, yhteydessä datapisteet, kutenidTag(RFID) taiEVCCID(Ajoneuvon tunnistetiedot) katsotaan henkilötiedoiksi.

OCPP 2.0.1 tarjoaa paremmat hallintaominaisuudet datan anonymisointiin. EsimerkiksiMukautettu datakentät mahdollistavat operaattoreille metadatan tallentamisen paljastamatta henkilötietoja ydinprotokollan lokitiedostoille. Lisäksi parannetut suojausprofiilit varmistavat, että tiedot salataan sekä siirron aikana että tallennettuina.

8.2 Oikeus tulla unohdetuksi ja tietojen siirrettävyys

2.0.1-laitemallin jäsennelty luonne helpottaa CSMS-palveluntarjoajien "tietojen poistopyyntöjen" toteuttamista. 1.6J-järjestelmässä kaikkien käyttäjätunnuksen esiintymien löytäminen erilaisista määritysavaimista ja lokeista oli manuaalinen painajainen. 2.0.1-versiossa laitteen tilan ja tapahtumatietojen selkeä erottelu mahdollistaa selkeämmän tietokanta-arkkitehtuurin.

8.3 IoT-tietoturvalakien noudattaminen

Monet alueet säätävät parhaillaan lakeja, jotka edellyttävät IoT-laitteilta yksilöllisiä salasanoja ja turvallisia päivitysmekanismeja. OCPP 2.0.1:n pakollinen TLS ja allekirjoitettu laiteohjelmisto eivät ole vain "mukavia lisäominaisuuksia" – ne ovat lakisääteisiä vaatimuksia laitteiston myynnille esimerkiksi Kalifornian ja Ison-Britannian kaltaisilla markkinoilla.

Luku 9: Ostajan näkökulma: kokonaiskustannukset, sijoitetun pääoman tuottoprosentti ja strateginen migraatio

Kaupalliselle latausasemien operaattorille päätös pitäytyä 1,6 joulen akussa tai siirtyä 2.0.1-versioon on taloudellinen.

9.1 Toteutuksen kustannukset

• OCPP 1.6JHalpa toteuttaa, laajalti tuettu halvalla laitteistolla, mutta sisältää korkeat piilokustannukset ylläpidon ja tietoturvariskien vuoksi.
• OCPP 2.0.1Vaatii tehokkaampia prosessoreita ja enemmän muistia EVSE:ssä. CSMS:n kehityskustannukset ovat korkeammat protokollan monimutkaisuuden vuoksi. Se tarjoaa kuitenkin merkittäviä käyttökustannussäästöjä etähallinnan ja paremman luotettavuuden ansiosta.

9.2 ”Sujuvan päivityksen” myytti

Usein sanotaan, että 1.6J-laturit voidaan päivittää 2.0.1-versioon ohjelmiston kautta. Todellisuudessa tämä harvoin pitää paikkansa. 2.0.1-version muisti- ja suoritinvaatimukset (erityisesti TLS-varmenteiden käsittely ja laitemallin monimutkainen JSON-jäsennys) ylittävät usein vanhempien 1.6J-ohjainten ominaisuudet.

9.3 Strategiset muuttoliikereitit

Tietojenkäsittelytieteen toimittajien tulisi harkita ”hybridiverkosto”-lähestymistapaa:

1. Vanhat sivustotJatka 1,6 joulen käyttöä olemassa oleville pienitehoisille verkkovirtalatureille.
2. Uudet DC-pikalatausasematMandaatti 2.0.1 kaikille uusille suuritehoisille käyttöönotoille PnC:n ja V2G:n tukemiseksi.
3. VälityspalvelinratkaisutKäytä protokollayhdyskäytävää, joka pystyy kääntämään 1.6J-viestit 2.0.1-yhteensopivaan muotoon CSMS:ää varten, mikä mahdollistaa yhden yhtenäisen hallintapaneelin.

Luku 10: Tulevaisuuden varalle: OCPP 2.1 ja tie autonomiseen lataukseen

Vaikka 2.0.1 on saamassa jalansijaa, Open Charge Alliance työskentelee jo OCPP 2.1:n parissa. Tämä tuleva versio laajentaa protokollan ulottuvuutta entisestään.

10.1 Kaksisuuntainen lataus (V2X)

Vaikka 2.0.1 tukee perus-V2G:tä, 2.1 tarkentaa ajoneuvosta kotiin (V2H) ja ajoneuvosta rakennukseen (V2B) -viestintää, jolloin sähköautot voivat ladata koteja sähkökatkosten aikana tai vähentää liikerakennusten huippukysyntää.

10.2 Langattoman latauksen tuki

Itseohjautuvien ajoneuvojen yleistyessä manuaalinen lataus jää pois käytöstä. OCPP 2.1 sisältää standardoidut viestit induktiivista (langatonta) latausta, linjauksen hallintaa ja energiansiirtoa varten ilman ihmisen puuttumista asiaan.

10.3 Integrointi älykkäiden kaupunkien kanssa

Tulevaisuudessa liikenteenhallintajärjestelmiin ja uusiutuvan energian ennusteisiin integroidaan todennäköisesti syvemmälle. Laturit voivat "tehdä tarjouksia" sähköstä reaaliaikaisilla energiamarkkinoilla, mikä muuttaa latausverkot massiivisiksi virtuaalisiksi voimalaitoksiksi (VPP).

Tekninen liite: Syvällinen katsaus viestien vertailuun

Jotta saisimme mahdollisimman kattavan teknisen selvityksen, analysoimme nyt tiettyjä viestisarjoja ja kehysten eroja kahden version välillä.

A.1 Valtuutusprosessi

Versiossa 1.6J valtuutus oli binaarinen "Hyväksytty"- tai "Estetty"-vastaus.

1.6J Valtuutusvastaus:”json [3, "123456", { "idTagInfo": { "status": "Hyväksytty", "expiryDate": "2026-12-31T23:59:59Z" } }]”

Versiossa 2.0.1 vastaus sisältää enemmän kontekstia, kutenidTokenkäyttöliittymän tyyppi ja lisätietoja.

2.0.1 Valtuutusvastaus:”json [3, "987654", { "idTokenInfo": { "status": "Hyväksytty", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "Tervetuloa takaisin, John! Saldosi on 45,00 $" } } }]”

A.2 Sydämen sykkeen ja yhteyksien hallinta

OCPP 2.0.1 optimoi aseman tavan todistaa olevansa "elossa". 1,6 joulen teholla, josSydämenlyöntiepäonnistui, asema usein vain yritti uudelleen. Versiossa 2.0.1 asema voi käyttääIlmoita tapahtumastamekanismi, joka ilmoittaa yhteyden katkeamisesta toissijaiseen taustajärjestelmään, mutta säilyttää silti yhteyden ensisijaiseen järjestelmään.

A.3 Yksityiskohtainen metatietotaulukko

Johtopäätös

Siirtyminen OCPP 1.6J:sta 2.0.1:een ei ole pelkkä ohjelmistopäivitys; se on sähköisen liikkuvuuden ekosysteemin perustavanlaatuinen kehitysaskel. Kaupallisille toimijoille 1.6J edustaa luotettavaa menneisyyttä, kun taas 2.0.1 edustaa skaalautuvaa, turvallista ja älykästä tulevaisuutta.

2.0.1:n valitseminen tänään on investointi pitkäikäisyyteen. Se varmistaa, että laitteistosi on yhteensopiva seuraavan sukupolven sähköautojen kanssa, täyttää tiukentuvat kyberturvallisuusmääräykset ja on valmis V2G:n ja älykkäiden verkkojen integroinnin tuottoisiin mahdollisuuksiin. Markkinoiden konsolidoituessa operaattorit, joilla on vankimmat ja joustavimmat protokollapinot, ovat johdossa.

Luku 11: Syvällinen analyysi: Viestivirta-analyysi ja sekvenssikaaviot

Tässä luvussa analysoimme EVSE:n ja CSMS:n välisiä vuorovaikutussekvenssejä havainnollistaaksemme 1.6J:n ja 2.0.1:n välisiä toiminnallisia eroja.

11.1 Käynnistys- ja konfigurointijärjestys

Kun laturi muodostaa yhteyden verkkoon ensimmäisen kerran, sen on tunnistettava itsensä ja synkronoitava kokoonpanonsa.

OCPP 1.6J virtaus:

1. WebSocket-yhteysMuodostettu portin 80 tai 443 kautta.
2. KäynnistysilmoitusAsema lähettää toimittajan, mallin ja sarjanumeron.
3. GetConfigurationCSMS pyytää kaikkia avaimia tarkistaakseen nykyisen tilan.
4. Muuta konfiguraatiotaCSMS päivittää tiettyjä avaimia (esim.Sydämenlyöntiväli).
5. TilailmoitusAsema ilmoittaa olevansa saatavilla.

OCPP 2.0.1 -virtaus:

1. Suojattu TLS-kättelyPakollinen todistuksen vaihto.
2. KäynnistysilmoitusSisältääsyy(esim,PowerUp).
3. GetBaseReportKaikkien avainten pyytämisen sijaan CSMS pyytää "perusraportin", joka sisältää laitemallin koko hierarkian.
4. Aseta muuttujatCSMS päivittää muuttujia. Huomaa, että versio 2.0.1 sallii atomitason päivitykset – useiden muuttujien asettaminen yhteen viestiin ja sen varmistaminen, että kaikki onnistuvat tai mikään ei onnistu.
5. Ilmoita tapahtumastaAsema raportoi komponenttien alkutilat.

11.2 Älykäs latausneuvottelu

Älykäs lataus on se, missä 2.0.1 todella loistaa, erityisesti useiden latausprofiilien käsittelyssä.

1.6J-versiossa CSMS lähettääAseta latausprofiilijoka määrittää pinotason ja aikataulun. Jos asemalla on useita liittimiä, profiilien käsittely on usein epäselvää.

Versiossa 2.0.1Aseta latausprofiilion nimenomaisesti linkitetty johonkinlatausprofiilin tarkoitus.

• Latausaseman maksimiprofiiliRajoittaa koko aseman ilmanottoa.
• TXDefaultProfile: Oletusarvo kaikille uusille tapahtumille.
• TXProfile: Käynnissä olevalle tapahtumalle ominaista.

Lisäksi 2.0.1 tukeeHae latauspinon tasoviestin, jonka avulla CSMS voi nähdä, mitkä profiilit ovat tällä hetkellä aktiivisia ja miten EVSE:n sisäinen ajoitustoiminto priorisoi niitä.

11.3 Kauko-ohjaus ja -liipaisu

Etäkomennot, kutenEtäkäynnistystapahtuma(1,6 J) on korvattuRequestStartTransaction(2.0.1). Keskeinen ero on hyötykuormassa. Versiossa 2.0.1 CSMS voi sisältäälatausprofiilisuoraan käynnistyspyynnössä. Tämä tarkoittaa, että auto voi aloittaa latauksen oikealla teholla välittömästi odottamatta toista viestiä, mikä vähentää viivettä ja parantaa verkon vakautta.

Luku 12: Matalatasoisten JSON-skeemojen ja kenttien vertailut

Kehittäjille ja järjestelmäintegraattoreille skeemamuutokset ovat migraation työläin osa.

12.1 Luettelotyypit (Enumit)

OCPP 2.0.1 laajentaa huomattavasti standardoitujen Enumien määrää, mikä vähentää 1.6J-toteutuksia vaivanneiden "mukautettujen" statuskoodien tarvetta.

• Syyluettelot: Vahtikoira, Ajoitettu nollaus, Etänollaus, Tehohäviö.
• Tilaluettelot: Miehitetty, Varattu, Ei saatavilla, Viallinen. 2.0.1 lisääSaatavilla, Miehitetty, Varattu, Ei saatavilla, Viallinenmutta alitiloilla lisätietoja varten.

12.2 Tietotyypit ja yksiköt

OCPP 2.0.1 virallistaa standardiyksiköiden (SI) käytön. Siinä missä 1.6J joskus jätti desimaalitarkkuuden määrittelemättömäksi, 2.0.1 käyttäädesimaaliteho- ja energia-arvojen tyypit, mikä varmistaa yhdenmukaisen laskutuksen eri toimittajien laitteistojen välillä.

Luku 13: Tapaustutkimus: Globaali CPO-siirtymä 1,6 joulusta 2.0.1 jouluun

Tarkastellaan hypoteettista skenaariota ”MegaChargesta”, eli CPO:sta, jolla on 10 000 latauspistettä.

13.1 Vaihe 1: Auditointi

MegaCharge havaitsi, että 40 % heidän 1,6 jousen latauspisteistään ei tukenut TLS 1.2 -salausta. Tämä tarkoitti, että kyseiset laturit eivät olleet oikeutettuja tuleviin valtion sopimuksiin.

13.2 Vaihe 2: CSMS-päivitys

Uuden asiakashallintajärjestelmän (CSMS) rakentamisen sijaan MegaCharge toteutti "OCPP-käännöskerroksen". Tämä kerros käsitteli 1.6J-yhteyksiä vanhalle laitteistolle ja 2.0.1-yhteyksiä uudelle laitteistolle, mutta paljasti yhtenäisen API:n mobiilisovellukselleen ja laskutusmoottorilleen.

13.3 Vaihe 3: Laitteiston vaihto

Vilkkaasti liikennöidyillä latauspaikoilla MegaCharge korvasi 1,6 joulen laturit 2.0.1-yhteensopivilla tasavirtapikalatureilla. Tuloksena oli 15 prosentin vähennys "käynnistys epäonnistui" -istuntojen määrässä, pääasiassa vankemman tekniikan ansiosta.Transaktiotapahtumakäsittely versiossa 2.0.1.

13.4 ROI-analyysi

Alkuinvestointi oli 2 miljoonaa dollaria. Huoltokäyntien väheneminen (laitemallin diagnostiikan ansiosta) säästi kuitenkin 400 000 dollaria vuodessa. Lisäksi mahdollisuus osallistua V2G-taajuusvastemarkkinoille tuotti 200 000 dollaria lisää vuosituloja. Takaisinmaksuaika oli noin 3,3 vuotta.

Luku 14: Ostajan lopullinen tarkistuslista OCPP 2.0.1 -hankintoihin

Kun arvioit uutta laitteistoa tai ohjelmistoa, käytä tätä tarkistuslistaa varmistaaksesi todellisen vaatimustenmukaisuuden:

14.1 Laitteistovaatimukset (EVSE)

• [ ]Suojausprofiilin 3 tukiTukeeko se asiakaspuolen varmenteiden hallintaa?
• [ ]KaksiydinprosessoriOnko TLS-salaukselle ja JSON-jäsennykselle riittävästi pelivaraa?
• [ ]Suojattu elementti (SE)Onko piirilevyllä laitteistopohjainen luottamusjuuri avainten tallentamista varten?
• [ ]ISO 15118-2/20 -valmisPystyykö ohjain käsittelemään PnC:n vaatimaa korkean tason tiedonsiirtoa?
• [ ]NäyttöominaisuudetTukeeko laitteisto hinta-/tilatietojen näyttämistä OCPP:n kautta?Tiedonsiirtovai natiiveja viestejä?

14.2 Ohjelmistovaatimukset (CSMS)

• [ ]Laitemallin visualisointiVoiko kojelaudassa näkyä laturin hierarkkinen näkymä?
• [ ]VarmentajaintegraatioVoiko CSMS automaattisesti myöntää ja kierrättää varmenteita?
• [ ]Transaktioiden täsmäytysMiten järjestelmä käsittelee "roikkuvat" tapahtumat vanhoista 1,6 joulen latureista?
• [ ]Älykäs latausmoottoriTukeeko se version 2.0.1 edistynyttä pinotason logiikkaa?
• [ ]SkaalautuvuusVoiko WebSocket-käsittelijä hallita yli 50 000 pysyvää TLS-yhteyttä samanaikaisesti?

Luku 15: Yleisten OCPP-toteutusongelmien vianmääritys

Jopa standardin kanssa toteutukset vaihtelevat. Tässä ovat yleisimmät ongelmat.

15.1 WebSocketin aikakatkaisut

Monet verkkopalomuurit sulkevat käyttämättömät TCP-yhteydet. JosSydämenlyöntivälion asetettu liian korkealle, laturi saattaa irrota.

• RatkaisuVarmistaSydämenlyöntivälion pienempi kuin palomuurin aikakatkaisu (yleensä 60–120 sekuntia).

15.2 Varmenneketjuongelmat

Yleinen virhe versiossa 2.0.1 on ”Epäluotettava varmenne” -virhe. Tämä tapahtuu yleensä, kun laturilla ei ole CSMS:n juurivarmennetta asennettuna.

• RatkaisuKäytäAsennussertifikaattiviesti käyttöönoton aikana varmistaakseen, että luottamusketju on valmis.

15.3 JSON-hyötykuorman koko

Jotkin 2.0.1-viestit (kutenGetBaseReport) voi olla erittäin suuri. Jos laturin puskuri on liian pieni, se pudottaa viestin.

• RatkaisuTarkistaViestikoko enintäänlaitemallin muuttujaa ja varmista, että CSMS noudattaa tätä rajoitusta.

Luku 16: Alueelliset sääntelymaisemat ja pöytäkirjavaltuudet

Siirtyminen OCPP 2.0.1:een ei ole pelkästään teknologian ohjaama; se on yhä enemmän lakikysymys.

16.1 Euroopan unioni (AFIR)

EU:n vaihtoehtoisten polttoaineiden infrastruktuuria koskeva asetus (AFIR) edellyttää hinnoittelun läpinäkyvyyttä ja yhteentoimivuutta. Vaikka siinä ei nimenomaisesti mainita OCPP 2.0.1:tä, "reaaliaikaisen tiedon jakamisen" ja "älykkään latauksen" vaatimus tekee siitä käytännössä ainoan käyttökelpoisen standardin uudelle julkiselle infrastruktuurille.

16.2 Pohjois-Amerikka (NEVI)

Yhdysvalloissa National Electric Vehicle Infrastructure (NEVI) -kaavaohjelma edellyttää, että latausasemien on oltava "yhteentoimivia". Kalifornian kaltaiset osavaltiot menevät pidemmälle, ja Kalifornian energiakomissio (CEC) ajaa ISO 15118 -tukea, joka, kuten olemme keskustelleet, on parasta toteuttaa OCPP 2.0.1:n kautta.

16.3 Kiina ja Aasian ja Tyynenmeren alue

Vaikka Kiinalla on omat standardinsa (GB/T), vientiin keskittyvät valmistajat ovat investoineet voimakkaasti OCPP 2.0.1:een. Australian ja Singaporen kaltaisilla markkinoilla julkisten latausverkkojen tarjouskilpailuissa käytetään nykyään lähes yksinomaan OCPP 2.0.1:tä ja Security Profile 3:a.

Luku 17: Toteutuskoodinpätkät: "Pääasiat"

Kehittäjien avuksi tarjoamme käsitteellisiä JSON-esityksiä monimutkaisille 2.0.1-tehtäville.

17.1 Varmenteiden kierrätysprosessi

Kun varmenteen voimassaoloaika on päättymässä, CSMS:n on käynnistettävä rotaatio.

1. CSMS lähettääAllekirjoitettu todistus:”json [2, "CERT-01", "Varmenne allekirjoitettu", { "certificateChain": "-----VARMENNUKSEN ALKAA-----\n...\n-----VARMENNUKSEN PÄÄTTYMINEN-----", "certificateType": "V2G" }]”

2. Asema vastaaHyväksytty:”json [3, "CERT-01", { "status": "Hyväksytty" }]”

3. Asema lähettääTietoturvatapahtumailmoitus:”json [2, "EVT-99", "Turvallisuustapahtuman ilmoitus", { "tyyppi": "Varmenteen kierretty", "aikaleima": "2026-08-09T10:00:00Z" }]”

17.2 Verkkoon mukautuvan latausprofiilin asettaminen

Kuvittele, että verkko-operaattorin on rajoitettava sähkönjakelua verkossa.

CSMS lähettääAseta latausprofiili:”json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "Latausaseman maksimiprofiili", "chargingProfileKind": "Absoluuttinen", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } } }]”

Luku 18: OCPP 2.0.1 -termien kattava sanasto

Selkeyden takaamiseksi kaikille sidosryhmille tarjoamme laajennetun sanaston.

• CSMS (latausasemien hallintajärjestelmä)Pilvialusta, joka ohjaa latausasemia.
• EVSE (sähköajoneuvojen syöttölaitteet)Fyysinen latausasema.
• OCPP (avoimen latauspisteen protokolla)Kieli, jota he puhuvat.
• OCA (avoimen maksun allianssi)Kieltä kirjoittava organisaatio.
• ISO 15118Auton ja laturin välinen protokolla.
• PnC (Plug and Charge)ISO 15118 -standardin ja OCPP 2.0.1:n mahdollistama käyttäjäkokemus.
• V2G (ajoneuvosta verkkoon): Auton sähkön lähettäminen takaisin sähköverkkoon.
• V2X (ajoneuvosta kaikkeen)Yleinen termi V2G:lle, V2H:lle ja V2B:lle.
• TLS (kuljetuskerroksen suojaus)Salaus, joka pitää tiedot turvassa.
• PKI (julkisen avaimen infrastruktuuri)Digitaalisten varmenteiden järjestelmä, jota käytetään turvallisuuden takaamiseksi.
• JSON (JavaScript-objektin merkintätapa)Viestien muoto.
• WebSocketPysyvä yhteys "putki", jonka läpi viestit kulkevat.
• LaitemalliHierarkkinen tapa 2.0.1 kuvaa laitteistoa.
• Komponentti: Laitteiston osa (esim. liitin).
• MuuttujaKomponentin ominaisuus (esim. Tila).
• OminaisuusMuuttujan metatiedot (esim. Arvo, Mutability).
• TransaktiotapahtumaYhtenäinen viesti kaikille istuntotiedoille versiossa 2.0.1.
• SydämenlyöntiJaksoittainen ”Olen elossa” -signaali.
• Käynnistysilmoitus"Hei, olen täällä" -signaali, kun laturi käynnistyy.
• TiedonsiirtoYleinen viesti toimittajakohtaisille laajennuksille (käytä varoen!).

Loppusanat: Moniprotokolla-aikakauden navigointi

Ostajana tai toimijana tärkein oppi on, että olemme astumassamoniprotokollainen aikakausiSeuraavien 3–5 vuoden ajan 1,6 J ja 2,0,1 J tulevat olemaan rinnakkain. Tasapaino on kuitenkin muuttumassa nopeasti.

Valitsemalla OCPP 2.0.1:n tänään et osta vain protokollaa, vaan ostat vakuutuksen. Varmistat, että verkkosi pystyy mukautumaan uusiin autoihin, uusiin lakeihin ja uusiin tulovirtoihin. 2.0.1:n monimutkaisuus on edistyksen hinta – hinta, joka maksaa itsensä takaisin parantuneena käyttöaikana, pienentyneenä riskinä ja erinomaisena asiakaskokemuksena.

Kaupallinen lataus ei ole enää kapea teollisuudenala, vaan se on tulevaisuuden liikennejärjestelmän selkäranka. Rakenna tämä selkäranka mahdollisimman vankalle perustalle: OCPP 2.0.1.

Luku 19: Kehitys OCPP 2.0.1:lle: Parhaat käytännöt ohjelmistokehittäjille

Siirtyminen 1.6J-koodikannasta 2.0.1-versioon ei ole refaktorointia; se on uudelleenkirjoitus. Kehittäjien on omaksuttava erilainen ajattelutapa.

19.1 Asynkroniteetin omaksuminen

Vaikka WebSocketit ovat luonnostaan ​​asynkronisia, 2.0.1:n monimutkaisuus tarkoittaa, että yksittäinen pyyntö (kutenGetBaseReport) käsittely resurssirajoitteisella EVSE:llä voi kestää useita sekunteja. CSMS-kehittäjien on toteutettava vankka aikakatkaisu- ja uudelleenyrityslogiikka, joka ottaa huomioon eri laitetoimittajien vaihtelevat käsittelynopeudet.

19.2 Tehokas JSON-jäsennys

JSON-jäsentäminen voi olla prosessoritehokasta. EVSE-laiteohjelmiston kanssa kehittäjien tulisi käyttää suoratoistopohjaisia ​​jäsentimiä sen sijaan, että koko hyötykuorma ladataan RAM-muistiin. Tämä on erityisen tärkeääIlmoita tapahtumastaviestit, jotka voivat sisältää satoja muuttujien päivityksiä yhdessä kehyksessä.

19.3 Tilakoneen käsittely

Transaktion tilakone versiossa 2.0.1 on jäykempi kuin versiossa 1.6J. Kehittäjien on noudatettava tarkasti siirtymäsääntöjäTransaktiotapahtumaEt voi esimerkiksi lähettääPäättynyttapahtuma ilman, että olet ensin lähettänytAloitettutapahtuma kyseiselle tietylletapahtumatunnus.

Luku 20: Testaus, validointi ja OCPP-yhteensopivuuden testaustyökalu (OCTT)

Yhteentoimivuus on OCPP:n lupaus, mutta se toteutuu vain tiukan testauksen avulla.

20.1 OCA-sertifioinnin rooli

Open Charge Alliance tarjoaa sertifiointiohjelman. Ostajien tulisi etsiä ”OCPP 2.0.1 Certified” -merkintää. Tämä sertifiointi varmistaa, että toteutus on läpäissyt sarjan automatisoituja testejä, jotka kattavat kaikki pakolliset profiilit.

20.2 OCTT:n käyttö

OCPP Compliance Test Tool (OCTT) on testauksen kultastandardi. Se simuloi sekä CSMS:ää että EVSE:tä.

• EVSE-valmistajille: Käytä OCTT:tä varmistaaksesi, että asemasi käsittelee "onnellinen polku" -skenaariot ja reunatapaukset (kuten verkkokatkokset laiteohjelmistopäivityksen aikana).
• CSMS-palveluntarjoajilleKäytä OCTT:tä varmistaaksesi, että taustajärjestelmäsi pystyy käsittelemään valtavan määrän viestejä ja 2.0.1:n tiukat tietoturvavaatimukset.

20.3 Kenttätestaus ja Interop-festivaalit

Automaattisen testauksen lisäksi OCA järjestää ”Plugfestejä”, joissa toimittajat testaavat laitteistojaan ja ohjelmistojaan toisiaan vastaan ​​todellisissa tilanteissa. Näissä tilanteissa havaitaan ja korjataan hienovaraisimmatkin virheet, kuten varmenteiden yhteensopimattomuus tai pienet JSON-muotoiluerot.

Luku 21: Syvällinen vertaileva taulukko: OCPP 2.0.1:n yli 60 toimintoa

Täydellisen vertailun tarjoamiseksi luokittelemme 2.0.1:n pääviestit ja vertaamme niitä 1.6J:n vastineisiin.

21.1 Valmistelu ja konfigurointi

21.2 Transaktioiden käsittely

21.3 Tietoturva ja laiteohjelmiston hallinta

21.4 Mitä taulukko merkitsee verkollesi

Taulukko tekee yhdestä asiasta kiistattoman: OCPP 2.0.1 ei ole 1.6J:n kosmeettinen uudelleennimeäminen. Uudet viestiperheet – tyypitetyt muuttujat, tapahtumapohjaiset tapahtumat ja varmenteiden hallinta – ovat Plug & Charge -toiminnon, älykkään latauksen ja sääntelyraportoinnin edellyttämiä putkistoja. Laturiin, joka puhuu vain 1.6J:tä, voidaan jälkiasentaa yhdyskäytävä, mutta CSMS, joka puhuu vain 1.6J:tä, ei voi tarjota sääntelyviranomaisten ja autonvalmistajien yhä vaatimaa tietoturvamallia. Laitteistoa arvioitaessa "2.0.1-valmis" tarkoittaa, että laiteohjelmisto toimitetaan tänään, ei ensi vuodelle. Ja koska OCPP 2.0.1 toimii JSON-over-WebSocketilla 1.6J:n SOAP-siirron sijaan, viestivirrat ovat kevyempiä ja paljon helpompia virheenkorjata – käytännön etu, jonka IT-tiimisi tuntee alusta alkaen.

Luku 22: Yhteenveto: Päivityspäätöksen tekeminen

Kaupalliselle toimijalle käytännön ohjeet ovat selkeät:

• Uusien käyttöönottojen oletusarvoisena versiona pitäisi olla OCPP 2.0.1.Tietoturvamalli, varmenteiden käsittely ja ISO 15118 -integraatio ovat edellytyksiä vuoden 2026 sääntely-ympäristölle.
• Nykyiset 1,6 jousimoottorilla varustetut autokannat eivät ole pulassa.Hallitut yhdyskäytävät ja kaksoisprotokollaiset CSMS-alustat kurovat umpeen kuilua, kun otat käyttöön 2.0.1-natiivin laitteiston.
• Testaa ennen kuin luotat.Käytä OCTT:tä, plugfestejä ja vaiheittaisia ​​käyttöönottoja – yhteentoimivuus on todistettu kentällä, eikä sitä oletettu datalehdessä.
• Vaadi muuttopolku kirjallisesti.Laturitoimittajasi tulisi julkaista laiteohjelmiston etenemissuunnitelma 1.6J:sta 2.0.1:een päivämäärineen, ei epämääräisine lupauksineen.

Toimintakehotus: Keskustele MIDA Powerin kanssa protokollastrategiastasi

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.