Az OCPP 1.6J és 2.0.1 stratégiai összehasonlítása kereskedelmi töltőállomások üzemeltetői számára

Az OCPP 1.6J és a 2.0.1 végleges stratégiai összehasonlítása a globális kereskedelmi töltőállomás-üzemeltetők számára: a hálózati skálázhatóság, a fejlett kiberbiztonság, az ISO 15118 integráció és a hosszú távú infrastruktúra jövőbiztossá tétele a fenntartható elektromos jármű növekedés érdekében.

Összefoglaló

Az elektromos járművek (EV) töltési környezete szeizmikus változáson megy keresztül. Ahogy a globális elterjedés felgyorsul, az elektromos járművek ellátó berendezései (EVSE) és a töltőállomás-kezelő rendszerek (CSMS) közötti interakciót szabályozó mögöttes kommunikációs protokollok a kereskedelmi töltésüzemeltetők (CPO-k) műszaki stratégiájának középpontjába kerültek. Az Open Charge Alliance (OCA) által fenntartott Open Charge Point Protocol (OCPP) egy egyszerű üzenetküldési keretrendszerből kifinomult, biztonságos és rendkívül skálázható szabvánnyá fejlődött.

Ez az útmutató kimerítő technikai elemzést nyújt az OCPP 1.6J-ről az OCPP 2.0.1-re való áttérésről. Bemutatjuk az architektúrális különbségeket, a biztonsági fejlesztéseket, az eszközkezelési paradigmákat és az ISO 15118 integrációjának kritikus szerepét. A vásárlók és az üzemeltetők számára ez a cikk végleges referenciaként szolgál a megalapozott beszerzési és migrációs döntések meghozatalához egy gyorsan fejlődő piacon.

1. fejezet: Az elektromosjármű-töltési szabványok fejlődése: történelmi kontextus

Az Open Charge Point Protocol (OCPP) az interoperabilitás iránti igényből született. Az elektromos járműtöltés korai napjaiban a hardvergyártók és szoftverszolgáltatók saját fejlesztésű protokollokat használtak, „zárt kerteket” létrehozva, amelyek elfojtották a versenyt és az innovációt. Az OCPP 1.2 és 1.5 bevezetése fektette le az alapokat, de az OCPP 1.6 egyesítette igazán az iparágat.

1.1 Az OCPP 1.6J dominanciája

A 2015-ben kiadott OCPP 1.6 bevezette a JSON over WebSockets (1.6J) implementációt. Ez az elmozdulás a SOAP-alapú üzenetküldéstől jelentősen csökkentette a fejlesztők terhelését és leegyszerűsítette a megvalósítást. Olyan funkciókat vezetett be, mint az intelligens töltés és a további állapotértesítések, így közel egy évtizedre iparági szabvánnyá vált.

1.2 Az OCPP 2.0.1 keletkezése

Az 1.6J sikere ellenére az iparág növekedése feltárta korlátait. A biztonsági problémák, az eszközkezelés bonyolultsága és a fejlett hálózati integráció (V2G) natív támogatásának hiánya az OCPP 2.0, majd később a finomított OCPP 2.0.1 (2020-ban jelent meg) kifejlesztéséhez vezetett. Az OCPP 2.0.1 nem csupán egy frissítés; egy teljes újratervezés, amelynek célja a nagy teljesítményű, intelligens és biztonságos töltőhálózatok következő generációjának támogatása.

2. fejezet: Alapvető kommunikációs paradigmák: JSON, WebSockets és keretstruktúrák

A protokollok közötti különbség megértéséhez meg kell vizsgálni az alacsony szintű kommunikációt. Mindkét protokoll JSON-t használ WebSocketeken keresztül, de az üzenetek szerkezete és kezelése jelentősen eltér.

2.1 A WebSocket réteg

Mindkét verzió perzisztens WebSocket kapcsolatokat használ, amelyek lehetővé teszik a teljes duplex kommunikációt. Ez kritikus fontosságú a valós idejű műveletekhez, például egy töltési munkamenet mobilalkalmazásból történő leállításához vagy azonnali hibajelzések fogadásához.

2.2 Üzenetkeret-lebontás

Egy tipikus OCPP üzenet egy üzenettípus-azonosítóból, egy egyedi üzenetazonosítóból, a művelet nevéből és a hasznos adatból áll.

OCPP 1.6J keret példa (BootNotification)

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

OCPP 2.0.1 keret példa (BootNotification)

„json [2, "987654", "BootNotification", { "reason": "PowerUp", "chargingStation": { "vendorName": "MidaPower", "model": "Terra-Z", "serialNumber": "SN-Z-99", "firmwareVersion": "v2.0.0" } }]`Figyeljük meg a megnövelt részletességet a 2.0.1-es verzióban.A „reason” mező lehetővé teszi a CSMS számára, hogy megértse, hogy a rendszerindítás újraindítás, bekapcsolás vagy watchdog trigger miatt történt-e, ami jobb diagnosztikai logikát tesz lehetővé.

3. fejezet: Építészeti paradigmaváltás: Az eszközmodell

Az OCPP 2.0.1 legjelentősebb technikai eltérése a következő bevezetése:Eszközmodell.

3.1 Az 1.6J konfigurációs kulcsok korlátai

Az OCPP 1.6J-ben a hardverkonfigurációt a „konfigurációs kulcsok” egyszerű listája (pl.SzívverésIntervallum, Kapcsolati időtúllépés). Ahogy a töltők egyre bonyolultabbá váltak (többcsatlakozósak, integrált tápegységek, komplex hűtőrendszerek), ez a lapos lista kezelhetetlenné vált. Nem volt szabványosított módja az állomás fizikai hierarchiájának leírására.

3.2 A 2.0.1-es eszközmodell-megközelítés

Az OCPP 2.0.1 egy hierarchikus modellt vezet be, amely a következőkből áll:AlkatrészekésVáltozókEgy komponens lehet a „Vezérlő”, a „Csatlakozó” vagy a „Tápellátási modul”. Minden komponenshez tartoznak olyan változók, amelyek az állapotát vagy konfigurációját jelölik (pl.Hőmérséklet, Feszültség, Max. áramerősség).

• ÖsszetevőA töltőállomás fizikai vagy logikai része.
• Változó: Az adott komponens egy adott attribútuma.
• JellemzőkA változót leíró metaadatok (mértékegység, tartomány, hozzáférési típus).

Ez lehetővé teszi a szabványosított monitorozást. A kezelő mostantól szabványosított útvonalon keresztül kérdezheti le egy adott teljesítménymodul hőmérsékletét, ahelyett, hogy a gyártóspecifikus saját kulcsokra hagyatkozna.

4. fejezet: Kiberbiztonság: A „legjobb erőfeszítéstől” a kötelező TLS-ig

Az elektromos járműtöltés korai napjaiban a biztonság gyakran másodlagos szempont volt. Az OCPP 1.6J biztonsági profilokat kínált, de a megvalósításuk nem volt egységes a különböző gyártók között.

4.1 Biztonsági profilok az 1.6J-ban

Az OCPP 1.6J három biztonsági profilt definiált:

1. Fedezet nélküliSima szöveges HTTP/WebSockets.
2. Alapszintű hitelesítésTLS felhasználónévvel/jelszóval.
3. TanúsítványalapúTLS kliensoldali tanúsítványokkal.

A probléma az volt, hogy sok töltő továbbra is az 1-es profilon maradt, így sebezhetővé váltak a közbeékelődéses (MITM) támadásokkal és a jogosulatlan irányítással szemben.

4.2 A 2.0.1-es verzió megkeményedett álláspontja

Az OCPP 2.0.1 biztonságos kommunikációt ír elő. Natívan integrálja a fejlett biztonsági funkciókat:

• Biztonságos firmware-frissítésekA firmware-képek kötelező aláírása és ellenőrzése.
• Biztonsági naplózásRészletes naplók a biztonsággal kapcsolatos eseményekről (pl. sikertelen bejelentkezési kísérletek, tanúsítvány lejárata).
• TanúsítványkezelésSzabványosított üzenetek a rotált és frissített tanúsítványokhoz (CSMS vagy állomás által vezérelve).
• TLS 1.2/1.3A legújabb titkosítási szabványok támogatása.

A kereskedelmi üzemeltetők számára ez csökkenti a hatalmas hálózati kompromittálódás kockázatát, és biztosítja az IoT-eszközökre vonatkozó újonnan megjelenő kiberbiztonsági előírások betartását.

5. fejezet: ISO 15118 integráció: Plug & Charge és V2G

Az elektromos járművek töltésének jövője nem csak az elektronok mozgatásáról szól; az adatok és az energia intelligens cseréjéről. Az ISO 15118 a jármű-hálózat (V2G) kommunikáció nemzetközi szabványa, és az OCPP-vel való integrációja a 2.0.1 meghatározó jellemzője.

5.1 A plug & Charge összetettsége

A Plug & Charge (PnC) lehetővé teszi a vezető számára, hogy egyszerűen csatlakoztassa a járművet a töltőhöz, és elkezdje a töltést alkalmazás vagy RFID-kártya használata nélkül. Ehhez összetett nyilvános kulcsú infrastruktúrára (PKI) van szükség, amely magában foglalja a járművet, a töltőt, az üzemeltetőt és a klíringházat.

Az OCPP 1.6J-ben a PnC támogatás nem létezett az alapprotokollban. A gyártóknak egyedi kiterjesztéseket kellett implementálniuk, ami fragmentációhoz vezetett. Az OCPP 2.0.1 a PnC „összetevőit” biztosítja a következők támogatásával:

• Tanúsítvány telepítéseSzerződéstanúsítványok továbbítása a CSMS-ből az EV-be az EVSE-n keresztül.
• EngedélyezésA jármű tanúsítványából származó e-Mobility ID (eMAID) használatával.
• Titkosított kommunikáció: Annak biztosítása, hogy az autó és a hálózat között továbbított érzékeny számlázási adatok védve legyenek.

5.2 Intelligens töltés és terheléselosztás

Míg az 1.6J támogatta az alapvető intelligens töltést (egyTöltési profil beállítása), a 2.0.1 ezt magasabb szintre emeli. Lehetővé teszi:

• Külső jelintegrációValós idejű válasz a hálózati frekvencia vagy a nagykereskedelmi árjelekre.
• Dinamikus terheléskezelésRészletesebb szabályozás az energiaelosztás felett egy több száz csatlakozóval rendelkező telephelyen.
• Járműtől a hálózatig (V2G)A 2.0.1 tartalmazza a kétirányú energiaáramlás támogatásához szükséges adatmezőket, lehetővé téve az elektromos járművek számára, hogy elosztott energiaforrásként (DER) működjenek a hálózat számára.

5.3 Felhasználói felület/UX fejlesztések

Az OCPP 2.0.1 támogatja az információk közvetlen megjelenítését a töltő képernyőjén vagy a jármű műszerfalán, például:

• Valós idejű árképzés a helyi pénznemben.
• A 80%-os töltöttségi szint (SoC) elérésének becsült ideje.
• Részletes átvételi információk a kitöltés után.

6. fejezet: Speciális eszközkezelés és -felügyelet

Egy töltő üzemeltetője (CPO) számára a töltő ára nem csak a vételár, hanem a teljes tulajdonlási költség (TCO). A karbantartás és az állásidő a legnagyobb profitcsökkentő tényezők. Az OCPP 2.0.1 ezt a problémát kiváló monitorozási képességekkel kezeli.

6.1 Eseményvezérelt jelentéskészítés

Az 1.6J-ban a CSMS-nek általában le kellett kérdeznie a töltő állapotát, vagy várnia kellett egy üzenetre.ÁllapotértesítésA 2.0.1-es verzióban aEseményfelügyeletA rendszer lehetővé teszi a CSMS számára küszöbértékek beállítását. Például: „Csak akkor értesítsen, ha a belső hőmérséklet meghaladja a 70°C-ot” vagy „Jelentés, ha a bemeneti feszültség 200V alá esik”. Ez csökkenti a hálózati forgalmat és lehetővé teszi a proaktív karbantartást.

6.2 Tranzakciókezelés: A TransactionEvent

Az OCPP 1.6J egyik leginkább kritizált aspektusa a tranzakciók kezelése volt. Egy munkamenet részt vett benneTranzakció indításaésTranzakció leállításaüzeneteket, de ha hálózati megszakítás történt, a CSMS gyakran nehézségekbe ütközött a számlázási adatok egyeztetése során.

Az OCPP 2.0.1 ezeket egyetlen, robusztusTranzakcióeseményüzenet. Ez az üzenet egy tranzakció összes életciklus-szakaszának (Elindítva, Frissítve, Befejezve) jelentésére szolgál. Tartalmaz egy egyeditranzakcióazonosítóami akkor is fennáll, ha a töltő újraindul, így biztosítva, hogy ne vesszen el töltési adat – és így bevétel sem.

6.3 Továbbfejlesztett diagnosztika és hibaelhárítás

ANapló beolvasásaésDiagnosztikaÁllapotértesítésA 2.0.1-es verzióban az üzenetek strukturáltabbak. A CPO-k kérhetnek meghatározott naplótípusokat (biztonsági, diagnosztikai, felhasználói), és megadhatják az időtartományt. Ez lehetővé teszi a távoli támogató csapatok számára, hogy technikus kiküldése nélkül oldják meg a problémákat, ami jelentősen csökkenti az üzemeltetési költségeket.

7. fejezet: Firmware frissítési mechanizmusok: Megbízhatóság és visszagörgetések

A firmware-frissítések a fejlődő hardverek éltető elemei, de egy sikertelen frissítés tönkretehet egy töltőt.

7.1 Az 1.6J frissítési folyamata

1,6 joulban aFirmware frissítéseA parancs viszonylag egyszerű volt. A töltő letöltötte a lemezképet és megpróbálta telepíteni. Nem volt szabványosított mechanizmus a többlépcsős frissítésekhez vagy az ellenőrzött visszagörgetésekhez.

7.2 A 2.0.1-es többlépcsős frissítés

Az OCPP 2.0.1 kifinomultabb életciklust vezet be a firmware-frissítésekhez:

1. Letöltés: A töltő lekéri a képet, és ellenőrzi annak ellenőrzőösszegét/aláírását.
2. Telepítés: A frissítés egy másodlagos partícióra lett alkalmazva.
3. Ellenőrzés: A rendszer ellenőrzi, hogy az új firmware megfelelően elindul-e.
4. AktiválásAz elsődleges partíció fel van cserélve.

Ha bármelyik lépés sikertelen, a protokoll meghatározza, hogyan kell a töltőnek visszaállnia az előző stabil verzióra, és hogyan kell jelentenie a konkrét hibakódot a CSMS-nek. Ez a megbízhatósági szint nagyszabású kereskedelmi telepítések esetén nem képezheti vita tárgyát.

7.3 Aláírás-ellenőrzés

A rosszindulatú szereplők általi feltört firmware feltöltésének megakadályozása érdekében a 2.0.1-es verzió előírja a digitális aláírások használatát. A töltő megtagadja a gyártó privát kulcsával nem aláírt kód végrehajtását, ezáltal kritikus védelmi réteget biztosítva a hardveres szintű hackek ellen.

8. fejezet: Adatvédelem, szabályozási megfelelés és a GDPR

Ahogy az elektromos járművek töltése mindennapi használati eszközzé válik, a keletkező személyes adatok mennyisége megdöbbentő. Egyetlen töltési munkamenet összekapcsolhatja a felhasználó személyazonosságát, járművének helyét, utazási szokásait és pénzügyi adatait.

8.1 Személyazonosításra alkalmas adatok (PII) az OCPP-ben

Az európai általános adatvédelmi rendelet (GDPR) és a hasonló törvények, például a kaliforniai CCPA összefüggésében olyan adatpontok, mint aazonosítócímke(RFID) vagy aEVCCID(Járműazonosító) adatok személyazonosításra alkalmas adatoknak minősülnek.

Az OCPP 2.0.1 jobb ellenőrzéseket biztosít az adatok anonimizálásához. Például aEgyéni adatokA mezők lehetővé teszik az operátorok számára a metaadatok tárolását anélkül, hogy a személyazonosításra alkalmas adatokat kitennék az alapvető protokollnaplóknak. Továbbá a továbbfejlesztett biztonsági profilok biztosítják, hogy ezek az adatok mind átvitel, mind tárolás közben titkosítva legyenek.

8.2 Az elfeledtetéshez való jog és az adathordozhatóság

A 2.0.1-es eszközmodell strukturált jellege megkönnyíti a CSMS-szolgáltatók számára az „adattörlési” kérelmek megvalósítását. Egy 1.6J-os rendszerben egy felhasználói azonosító összes előfordulásának megtalálása a különböző konfigurációs kulcsokban és naplókban manuális rémálom volt. A 2.0.1-es verzióban az eszközállapot és a tranzakciós adatok egyértelmű szétválasztása lehetővé teszi a tisztább adatbázis-architektúrát.

8.3 Megfelelés az IoT biztonsági törvényeinek

Sok régióban most fogadnak el törvényeket, amelyek előírják, hogy az IoT-eszközök egyedi jelszavakkal és biztonságos frissítési mechanizmusokkal rendelkezzenek. Az OCPP 2.0.1 kötelező TLS- és aláírt firmware-je nem csupán „jó, ha van” funkciók – ezek jogi követelmények a hardverek értékesítéséhez olyan piacokon, mint Kalifornia és az Egyesült Királyság.

9. fejezet: A vevő nézőpontja: teljes tulajdonlási költség (TCO), megtérülés (ROI) és stratégiai migráció

Egy kereskedelmi töltőállomás-üzemeltető számára pénzügyi döntés, hogy az 1,6 joule-nál maradjon, vagy a 2.0.1-re váltson.

9.1 A megvalósítás költsége

• OCPP 1.6JOlcsón megvalósítható, széles körben támogatott alacsony költségű hardverekkel, de magas rejtett költségekkel jár a karbantartás és a biztonsági kockázatok tekintetében.
• OCPP 2.0.1Erősebb processzorokat és több memóriát igényel az EVSE-ben. A CSMS fejlesztési költségei magasabbak a protokoll összetettsége miatt. Azonban jelentős üzemeltetési költségmegtakarítást kínál a távoli felügyelet és a jobb megbízhatóság révén.

9.2 A „sima frissítés” mítosza

Gyakran mondják, hogy az 1.6J-os töltők szoftveresen frissíthetők a 2.0.1-es verzióra. A valóságban ez ritkán igaz. A 2.0.1 memória- és CPU-igénye (különösen a TLS-tanúsítványok kezelése és az eszközmodell összetett JSON-elemzése) gyakran meghaladja a régebbi 1.6J-os vezérlők képességeit.

9.3 Stratégiai migrációs útvonalak

A CPO-knak fontolóra kell venniük a „hibrid hálózati” megközelítést:

1. Régi webhelyekTovábbra is 1,6 J-t kell használni a meglévő alacsony fogyasztású váltakozó áramú töltők esetében.
2. Új DC gyorstöltő állomások: A 2.0.1-es megbízás minden új nagy teljesítményű telepítésre vonatkozik a PnC és a V2G támogatása érdekében.
3. Proxy megoldásokHasználjon olyan protokollátjárót, amely képes az 1.6J üzeneteket 2.0.1-kompatibilis formátumra fordítani a CSMS számára, lehetővé téve egyetlen, egységes felügyeleti irányítópult használatát.

10. fejezet: Jövőállóság: OCPP 2.1 és az önvezető töltés felé vezető út

Miközben a 2.0.1 egyre népszerűbb, az Open Charge Alliance már dolgozik az OCPP 2.1-en. Ez a jövőbeli verzió tovább bővíti a protokoll hatókörét.

10.1 Kétirányú töltés (V2X)

Míg a 2.0.1-es verzió támogatja az alapvető V2G-t, a 2.1-es verzió finomítja a jármű-otthon (V2H) és a jármű-épület (V2B) kommunikációt, lehetővé téve az elektromos járművek számára, hogy áramszünetek esetén is lássák el otthonaikat árammal, vagy csökkentsék a kereskedelmi épületek csúcsterhelését.

10.2 Vezeték nélküli töltés támogatása

Az önvezető járművek (AV) megjelenésével a manuális töltés elavulttá válik. Az OCPP 2.1 szabványosított üzeneteket fog tartalmazni az induktív (vezeték nélküli) töltéshez, a beállítás kezeléséhez és az energiaátvitelhez emberi beavatkozás nélkül.

10.3 Integráció az intelligens városokkal

A jövőbeli verziók valószínűleg mélyebb integrációt fognak tartalmazni a forgalomirányítási rendszerekkel és a megújuló energia előrejelzésekkel. A töltők képesek lesznek „licitálni” az energiára valós idejű energiapiacokon, így a töltőhálózatok hatalmas virtuális erőművekké (VPP-k) válnak.

Technikai függelék: Az üzenet-összehasonlítások mélyreható elemzése

A teljes technikai mélység biztosítása érdekében most elemezni fogjuk a két verzió közötti konkrét üzenetsorozatokat és keretkülönbségeket.

A.1 Az engedélyezési folyamat

Az 1.6J verzióban az engedélyezés egy bináris „Elfogadva” vagy „Blokkolva” válasz volt.

1.6J Engedélyezési válasz:„json [3, "123456", { "idTagInfo": { "status": "Elfogadva", "expiryDate": "2026-12-31T23:59:59Z" } }]„

A 2.0.1-es verzióban a válasz több kontextust tartalmaz, például aidTokentípus és további információk a felhasználói felületről.

2.0.1 AuthorizeResponse:„json [3, "987654", { "idTokenInfo": { "status": "Elfogadva", "cacheExpiryDateTime": "2026-12-31T23:59:59Z", "personalMessage": { "format": "UTF8", "content": "Üdv újra, John! Az egyenleged $45.00" } } }]„

A.2 Szívverés- és kapcsolatkezelés

Az OCPP 2.0.1 optimalizálja, hogyan bizonyítja az állomás az „élő” állapotát. 1,6J-ban, ha egySzívveréssikertelen volt, az állomás gyakran csak újra próbálkozott. A 2.0.1-es verzióban az állomás használhatja aÉrtesítési eseménymechanizmus, amely jelenti, ha a másodlagos háttérrendszerrel való kapcsolata megszakadt, miközben továbbra is fenntartja a szívverést az elsődlegessel.

A.3 Részletes metaadat-tábla

Következtetés

Az OCPP 1.6J-ról a 2.0.1-re való átállás nem pusztán szoftverfrissítés; az elektromos mobilitás ökoszisztémájának alapvető fejlődése. A kereskedelmi üzemeltetők számára az 1.6J a megbízható múltat, míg a 2.0.1 a skálázható, biztonságos és intelligens jövőt jelképezi.

A 2.0.1-es verzió választása ma befektetés a hosszú élettartamba. Biztosítja, hogy hardverei kompatibilisek lesznek a következő generációs elektromos járművekkel, megfelelnek a szigorodó kiberbiztonsági előírásoknak, és készen állnak a V2G és az intelligens hálózatok integrációjában rejlő jövedelmező lehetőségekre. Ahogy a piac konszolidálódik, a legrobusztusabb és legrugalmasabb protokollkészlettel rendelkező szolgáltatók lesznek azok, akik vezetik a versenyt.

11. fejezet: Mélymerülés: Üzenetfolyam-elemzés és szekvenciadiagramok

Ebben a fejezetben az EVSE és a CSMS közötti interakciós szekvenciákat elemezzük, hogy bemutassuk az 1.6J és a 2.0.1 közötti működési különbségeket.

11.1 A rendszerindítási és konfigurációs sorrend

Amikor egy töltő először csatlakozik a hálózathoz, azonosítania kell magát, és szinkronizálnia kell a konfigurációját.

OCPP 1.6J áramlás:

1. WebSocket kapcsolat: A 80-as vagy 443-as porton keresztül létrehozva.
2. Boot NotificationAz állomás elküldi a szállítót, a modellt és a sorozatszámot.
3. Konfiguráció beolvasásaA CSMS lekéri az összes kulcsot az aktuális állapot ellenőrzéséhez.
4. Konfiguráció módosításaA CSMS frissíti a megadott kulcsokat (pl.SzívverésIntervallum).
5. ÁllapotértesítésAz állomás jelentése: „Elérhető”.

OCPP 2.0.1 folyamat:

1. Biztonságos TLS kézfogásKötelező tanúsítványcsere.
2. Boot NotificationTartalmazzaok(például,PowerUp).
3. GetBaseReportAz összes kulcs lekérése helyett a CSMS egy „Alapjelentést” kér, amely az eszközmodell teljes hierarchiáját tartalmazza.
4. Változók beállítása: A CSMS frissíti a változókat. Fontos megjegyezni, hogy a 2.0.1-es verzió lehetővé teszi az atomi frissítéseket – több változó beállítását egyetlen üzenetben, és annak biztosítását, hogy mindegyik sikeres legyen, vagy egyik sem.
5. Értesítési eseményAz állomás jelenti a kezdeti komponensállapotokat.

11.2 Az intelligens töltési tárgyalás

Az intelligens töltés az, ahol a 2.0.1 igazán ragyog, különösen több töltési profil kezelésekor.

1.6J-ban a CSMS küld egyTöltési profil beállításaamely egy veremszintet és egy ütemezést definiál. Ha egy állomásnak több csatlakozója van, a profilkezelés gyakran kétértelmű.

A 2.0.1-es verzióban aTöltési profil beállításaexplicit módon kapcsolódik egytöltési profilCél.

• TöltőállomásMaxProfil: Korlátozza az egész állomás beáramlását.
• TXDefaultProfile: Az alapértelmezett érték minden új tranzakcióhoz.
• TXProfile: Egy folyamatban lévő tranzakcióra jellemző.

Továbbá a 2.0.1 támogatja a következőket:Töltési szint lekéréseüzenetet, amely lehetővé teszi a CSMS számára, hogy lássa, mely profilok aktívak jelenleg, és hogyan rangsorolja azokat az EVSE belső ütemezője.

11.3 Távoli indítás és vezérlés

Távoli parancsok, mint példáulTávoliTranzakcióIndítása(1,6 J) helyébe a következő kerültRequestStartTranzakció(2.0.1). A fő különbség a hasznos adatmennyiségben rejlik. A 2.0.1-ben a CSMS tartalmazhat egytöltési profilközvetlenül az indítási kérésben. Ez azt jelenti, hogy az autó azonnal elkezdheti a töltést a megfelelő teljesítményszinten, anélkül, hogy egy második üzenetre kellene várnia, csökkentve a késleltetést és javítva a hálózat stabilitását.

12. fejezet: Alacsony szintű JSON sémák és mezők összehasonlítása

A fejlesztők és a rendszerintegrátorok számára a sémamódosítások jelentik a migráció legmunkaigényesebb részét.

12.1 Felsorolt ​​típusok (Enumok)

Az OCPP 2.0.1 jelentősen kibővíti a szabványosított enumok számát, csökkentve az „egyéni” állapotkódok szükségességét, amelyek az 1.6J implementációkat sújtották.

• Indoklási felsorolások: Őrzőkutya, Ütemezett visszaállítás, Távoli visszaállítás, Teljesítményveszteség.
• Állapotfelsorolások: Megszállt, Fenntartott, Nem elérhető, HibásA 2.0.1-es verzió hozzáadja a következőket:Elérhető, Megszállt, Fenntartott, Nem elérhető, Hibásde a részletekért alállapotokkal is.

12.2 Adattípusok és mértékegységek

Az OCPP 2.0.1 formalizálja a standard mértékegységek (SI) használatát. Míg az 1,6J néha nem definiálta a decimális pontosságot, a 2.0.1 ezt használja.decimálisenergia- és teljesítményértékek típusai, biztosítva a különböző gyártók hardverei közötti egységes számlázást.

13. fejezet: Esettanulmány: Globális CPO-migráció 1,6 J-ról 2,0,1-re

Nézzünk egy hipotetikus forgatókönyvet a „MegaCharge”-ról, egy 10 000 töltési ponttal rendelkező CPO-ról.

13.1 1. fázis: Az audit

A MegaCharge felfedezte, hogy 1.6J-os flottájuk 40%-a nem támogatja a TLS 1.2-t. Ez azt jelentette, hogy ezek a töltők nem voltak jogosultak a közelgő kormányzati szerződésekre.

13.2 2. fázis: A CSMS frissítése

Egy új CSMS kiépítése helyett a MegaCharge egy „OCPP fordítási réteget” valósított meg. Ez a réteg 1.6J kapcsolatokat kezelt a régi hardvereknél és 2.0.1-et az új hardvereknél, de egy egységes API-t tett elérhetővé a mobilalkalmazásuk és a számlázási motorjuk számára.

13.3 3. fázis: Hardvercsere

A nagy forgalmú helyszíneken a MegaCharge az 1,6 joule-os töltőket 2.0.1-kompatibilis egyenáramú gyorstöltőkre cserélte. Az eredmény a „Sikertelen indítás” típusú munkamenetek 15%-os csökkenése volt, elsősorban a robusztusabb működésnek köszönhetően.Tranzakcióeseménykezelés a 2.0.1 verzióban.

13.4 ROI-elemzés

A kezdeti befektetés 2 millió dollár volt. Azonban a csökkent karbantartási hívások (az eszközmodell diagnosztikájának köszönhetően) évi 400 ezer dollár megtakarítást eredményeztek. Ezenkívül a V2G frekvenciaválasz-piacokon való részvétel lehetősége további 200 ezer dollár éves bevételt generált. A megtérülési idő körülbelül 3,3 év volt.

14. fejezet: A vevő végső ellenőrzőlistája az OCPP 2.0.1 beszerzéshez

Új hardver vagy szoftver értékelésekor használja ezt az ellenőrzőlistát a valódi megfelelőség biztosításához:

14.1 Hardverkövetelmények (EVSE)

• [ ]3. biztonsági profil támogatásaTámogatja a kliensoldali tanúsítványkezelést?
• [ ]Kétmagos processzorVan elég szabad hely a TLS titkosításhoz és a JSON elemzéshez?
• [ ]Biztonságos elem (SE)Van a panelnek hardveres bizalmi gyökere a kulcsok tárolására?
• [ ]ISO 15118-2/20 szabványnak megfelelőKépes-e a vezérlő kezelni a PnC-hez szükséges magas szintű kommunikációt?
• [ ]Kijelzőképesség: A hardver támogatja az ár/állapot információk megjelenítését OCPP-n keresztül?Adatátvitelvagy natív üzenetek?

14.2 Szoftverkövetelmények (CSMS)

• [ ]Eszközmodell-vizualizációMegjeleníthető a műszerfalon a töltő hierarchikus nézete?
• [ ]Tanúsítványhatóság (CA) integrációKépes-e a CSMS automatikusan tanúsítványokat kiállítani és rotálni?
• [ ]TranzakcióegyeztetésHogyan kezeli a rendszer a korábbi 1,6 jonos töltők „lefagyott” tranzakcióit?
• [ ]Intelligens töltőmotorTámogatja a 2.0.1-es verzió fejlett stack-szintű logikáját?
• [ ]SkálázhatóságKépes a WebSocket kezelő egyszerre több mint 50 000 perzisztens TLS-kapcsolatot kezelni?

15. fejezet: Gyakori OCPP implementációs problémák elhárítása

Még egy szabvány esetén is eltérőek a megvalósítások. Íme a leggyakoribb „buktatók”.

15.1 WebSocket időtúllépések

Sok hálózati tűzfal lezárja az üresjárati TCP-kapcsolatokat. Ha aSzívverésIntervallumtúl magasra van állítva, előfordulhat, hogy a töltő le van választva.

• MegoldásBiztosítsaSzívverésIntervallumalacsonyabb, mint a tűzfal időkorlátja (általában 60-120 másodperc).

15.2 Tanúsítványlánccal kapcsolatos problémák

A 2.0.1-es verzióban egy gyakori hiba a „Nem megbízható tanúsítvány” hiba. Ez általában akkor fordul elő, ha a töltőn nincs telepítve a CSMS legfelső szintű hitelesítésszolgáltatója.

• Megoldás: Használja aTanúsítvány telepítéseüzenetet az üzembe helyezés során, hogy megbizonyosodjon a bizalmi lánc teljességéről.

15.3 JSON hasznos teher mérete

Néhány 2.0.1-es üzenet (példáulGetBaseReport) nagyon nagy lehet. Ha a töltő puffermemóriája túl kicsi, akkor eldobja az üzenetet.

• Megoldás: Ellenőrizze aMaxMessageSizeváltozó az Eszközmodellben, és gondoskodjon arról, hogy a CSMS tiszteletben tartsa ezt a korlátot.

16. fejezet: Regionális szabályozási környezet és jegyzőkönyvi megbízások

Az OCPP 2.0.1-re való áttérés nem pusztán technológiai okokból történt; egyre inkább jogi kérdés is.

16.1 Az Európai Unió (AFIR)

Az EU alternatív üzemanyag-infrastruktúráról szóló rendelete (AFIR) előírja az árak átláthatóságát és az interoperabilitást. Bár nem nevezi meg kifejezetten az OCPP 2.0.1-et, a „valós idejű adatmegosztás” és az „intelligens töltés” ​​követelménye gyakorlatilag a 2.0.1-et teszi az egyetlen életképes szabványgá az új közinfrastruktúra számára.

16.2 Észak-Amerika (NEVI)

Az Egyesült Államokban a Nemzeti Elektromos Jármű Infrastruktúra (NEVI) formulaprogramja előírja, hogy a töltőknek „interoperábilisnak” kell lenniük. Egyes államok, mint Kalifornia, ennél is tovább mennek, a Kaliforniai Energiaügyi Bizottság (CEC) pedig az ISO 15118 támogatását szorgalmazza, amelyet, mint már említettük, a legjobb az OCPP 2.0.1-en keresztül megvalósítani.

16.3 Kína és Ázsia-Csendes-óceáni térség

Míg Kínának saját szabványai vannak (GB/T), az exportra orientált gyártók jelentős összegeket fektetnek be az OCPP 2.0.1-be. Az olyan piacokon, mint Ausztrália és Szingapúr, a nyilvános töltőhálózatokra vonatkozó kormányzati pályázatok ma már szinte kizárólag az OCPP 2.0.1-et és a 3-as biztonsági profilt írják elő.

17. fejezet: Megvalósítási kódrészletek: A lényeg

A fejlesztők segítése érdekében koncepcionális JSON reprezentációkat biztosítunk összetett 2.0.1-es feladatokhoz.

17.1 Tanúsítványrotációs folyamat

Amikor egy tanúsítvány lejárata közeledik, a CSMS-nek rotációt kell indítania.

1. A CSMS küldiAláírt tanúsítvány:„json [2, "CERT-01", "Tanúsítvány aláírva", { "certificateChain": "-----TANÚSÍTVÁNY KEZDETE-----\n...\n-----TANÚSÍTVÁNY VÉGE-----", "certificateType": "V2G" }]„

2. Az állomás válaszolElfogadott:„json [3, "CERT-01", { "állapot": "Elfogadva" }]„

3. Állomás küldBiztonsági eseményértesítés:„json [2, "EVT-99", "BiztonságiEventNotification", { "típus": "TanúsítványElforgatva", "időbélyeg": "2026-08-09T10:00:00Z" }]„

17.2 Hálózatalapú töltési profil beállítása

Képzeljük el, hogy a hálózat üzemeltetőjének csökkentenie kell a hálózaton keresztüli áramellátást.

CSMS küldTöltési profil beállítása:„json [2, "GRID-REQ", "SetChargingProfile", { "evseId": 0, "chargingProfile": { "id": 501, "stackLevel": 1, "chargingProfilePurpose": "ChargingStationMaxProfile", "chargingProfileKind": "Abszolút", "chargingSchedule": { "id": 1, "chargingRateUnit": "W", "chargingSchedulePeriod": [ { "startPeriod": 0, "limit": 11000 }, { "startPeriod": 3600, "limit": 22000 } ] } } }]„

18. fejezet: Az OCPP 2.0.1 kifejezések átfogó szószedete

Az összes érdekelt fél számára biztosítandó egyértelműség érdekében bővített szószedetet biztosítunk.

• CSMS (töltőállomás-kezelő rendszer): A töltőket vezérlő háttér-felhőplatform.
• EVSE (Elektromos Jármű Ellátó Berendezés)A fizikai töltőállomás.
• OCPP (Nyílt Töltési Pont Protokoll): A nyelv, amelyet beszélnek.
• OCA (Nyílt Töltésű Szövetség): A nyelvet író szervezet.
• ISO 15118: Az autó és a töltő közötti protokoll.
• PnC (csatlakoztasd és töltsd)Az ISO 15118 és az OCPP 2.0.1 által lehetővé tett felhasználói élmény.
• V2G (járműtől a hálózatig): Az autóból visszatáplált energia a hálózatba.
• V2X (Járműtől mindenhez)A V2G, V2H és V2B gyűjtőfogalom.
• TLS (Szállítási réteg biztonsága): A titkosítás, amely biztonságban tartja az adatokat.
• PKI (nyilvános kulcsú infrastruktúra)A biztonság érdekében használt digitális tanúsítványok rendszere.
• JSON (JavaScript objektumjelölés): Az üzenetek formátuma.
• WebSocketAz állandó kapcsolat „csöve”, amelyen keresztül az üzenetek áramlanak.
• EszközmodellA 2.0.1-es hierarchikus mód hardvert ír le.
• Összetevő: A hardver egy darabja (pl. csatlakozó).
• VáltozóEgy komponens tulajdonsága (pl. Állapot).
• AttribútumVáltozó metaadatai (pl. Érték, Mutability).
• Tranzakcióesemény: Az összes munkamenet-adat egységes üzenete a 2.0.1-es verzióban.
• SzívverésA periodikus „Élek” jelzés.
• Boot Notification: A „Helló, itt vagyok” jelzés, amikor a töltő elindul.
• Adatátvitel: Gyártóspecifikus bővítményekre vonatkozó „gyűjtőüzenet” (óvatosan használja!).

Záró gondolatok: Eligazodni a többprotokollos korszakban

Vevőként vagy üzemeltetőként a legfontosabb tanulság az, hogy belépünk egytöbbprotokollos korszakA következő 3-5 évben az 1,6 J és a 2,0,1 együtt fog létezni. Az egyensúly azonban gyorsan változik.

Az OCPP 2.0.1 választásával ma nem csupán egy protokollt vásárol, hanem biztosítást is. Biztosítja, hogy hálózata alkalmazkodni tudjon az új autókhoz, az új törvényekhez és az új bevételi forrásokhoz. A 2.0.1 összetettsége a fejlődés ára – egy olyan ár, amely a jobb üzemidő, a csökkent kockázat és a kiváló ügyfélélmény révén megtérül.

A kereskedelmi töltés már nem egy réspiac, hanem a jövő közlekedési rendszerének gerince. Építsd ezt a gerincet a lehető legszilárdabb alapra: OCPP 2.0.1.

19. fejezet: Fejlesztés OCPP 2.0.1-re: Ajánlott gyakorlatok szoftvermérnökök számára

Az 1.6J kódbázisról a 2.0.1-re való átállás nem refaktorálás, hanem átírás. A fejlesztőknek egy másik mentális modellt kell alkalmazniuk.

19.1 Az aszinkronitás elfogadása

Bár a WebSocketek eredendően aszinkronok, a 2.0.1 összetettsége azt jelenti, hogy egyetlen kérés (mint példáulGetBaseReport) feldolgozása több másodpercig is eltarthat egy erőforrás-korlátozott EVSE-n. A CSMS fejlesztőknek robusztus időtúllépési és újrapróbálkozási logikát kell megvalósítaniuk, amely figyelembe veszi a különböző hardvergyártók eltérő feldolgozási sebességét.

19.2 Hatékony JSON elemzés

A JSON elemzés CPU-igényes lehet. Az EVSE firmware esetében a fejlesztőknek stream-alapú elemzőket kell használniuk a teljes hasznos adat RAM-ba töltése helyett. Ez különösen fontos a következők esetében:Értesítési eseményüzenetek, amelyek egyetlen keretben több száz változófrissítést is tartalmazhatnak.

19.3 Az állapotgép kezelése

A 2.0.1-es verzióban a tranzakciók állapotgépe merevebb, mint az 1.6J-ben. A fejlesztőknek szigorúan be kell tartaniuk az átmeneti szabályokat a következőkhöz:TranzakcióeseményPéldául nem küldhetsz egyBefejeződöttesemény anélkül, hogy először elküldte volnaElindítvaesemény az adott témábantranzakcióazonosító.

20. fejezet: Tesztelés, validálás és az OCPP megfelelőségi teszteszköz (OCTT)

Az OCPP ígérete az interoperabilitás, de ez csak szigorú teszteléssel valósul meg.

20.1 Az OCA-tanúsítvány szerepe

Az Open Charge Alliance egy tanúsítási programot kínál. A vásárlóknak az „OCPP 2.0.1 Certified” címkét kell keresniük. Ez a tanúsítvány biztosítja, hogy a megvalósítás egy sor automatizált teszten esett át, amelyek minden kötelező profilt lefedtek.

20.2 Az OCTT használata

Az OCPP megfelelőségi teszteszköz (OCTT) a tesztelés aranystandardja. Szimulálja mind a CSMS-t, mind az EVSE-t.

• EVSE gyártók számára: Az OCTT segítségével ellenőrizze, hogy az állomás kezeli-e a „boldog útvonal” forgatókönyveket és a szélsőséges eseteket (például a hálózati kieséseket firmware-frissítés közben).
• CSMS-szolgáltatók számáraHasználj OCTT-t annak biztosítására, hogy a backend képes legyen kezelni a hatalmas mennyiségű üzenetet és a 2.0.1 szigorú biztonsági követelményeit.

20.3 Terepi tesztelés és interopfesztiválok

Az automatizált tesztelésen túl az OCA „Plugfesteket” is szervez, ahol a gyártók hardvereiket és szoftvereiket valós körülmények között tesztelik egymással szemben. Itt a legapróbb hibákat – például a tanúsítványok inkompatibilitását vagy a kisebb JSON formázási különbségeket – is kiszűrik és kijavítják.

21. fejezet: Mély összehasonlító táblázat: Az OCPP 2.0.1 több mint 60 művelete

A teljes áttekintés érdekében kategorizáljuk a 2.0.1-es verzió fő üzeneteit, és összehasonlítjuk azokat az 1.6J-es megfelelőivel.

21.1 Kiépítés és konfiguráció

21.2 Tranzakciókezelés

21.3 Biztonság és firmware-kezelés

21.4 Mit jelent a táblázat a hálózatod számára?

A táblázat egy pontot félreérthetetlenül alátámaszt: az OCPP 2.0.1 nem az 1.6J kozmetikai átnevezése. Az új üzenetcsaládok – típusos változók, eseményvezérelt tranzakciók és tanúsítványkezelés – a Plug & Charge, az intelligens töltés és a szabályozási jelentéskészítés alapvető elemei. Egy olyan töltő, amely csak 1.6J-ban beszél, utólag felszerelhető átjáróval, de egy olyan CSMS, amely csak 1.6J-ban beszél, nem tudja biztosítani azt a biztonsági modellt, amelyet a szabályozók és az autógyártók egyre inkább megkövetelnek. A hardver értékelésekor a „2.0.1-kompatibilis” jelzésnek azt kell jelentenie, hogy a firmware ma kerül forgalomba, nem pedig a jövő évre van ütemezve. És mivel az OCPP 2.0.1 JSON-over-WebSocket protokollon fut, nem pedig az 1.6J SOAP átvitelén, az üzenetfolyamok könnyebbek és sokkal könnyebben hibakereshetők – ez egy gyakorlati előny, amelyet az informatikai csapata az első naptól kezdve érezni fog.

22. fejezet: Konklúzió: A frissítésről szóló döntés meghozatala

Egy kereskedelmi üzemeltető számára a gyakorlati útmutató egyértelmű:

• Az új telepítéseknek alapértelmezés szerint az OCPP 2.0.1-es verzióját kell használniuk.A biztonsági modell, a tanúsítványkezelés és az ISO 15118 integráció előfeltételei a 2026-os szabályozási környezetnek.
• A meglévő 1,6J-s flották nem állnak le a piacon.A felügyelt átjárók és a kétprotokollos CSMS platformok áthidalják a szakadékot, miközben Ön fokozatosan bevezeti a 2.0.1-natív hardvereket.
• Tesztelj, mielőtt megbízol.Használjon OCTT-t, plugfesteket és szakaszos bevezetést – az interoperabilitás a terepen bizonyított, nem az adatlap alapján feltételezett.
• Írásban kérjen egy migrációs útvonalat.A töltő gyártójának közzé kellene tennie egy firmware-ütemtervet az 1.6J-tól a 2.0.1-ig terjedő verzióról, dátumokkal, nem homályos ígéretekkel.

Cselekvésre való felhívás: Beszéljen a MIDA Powerrel a protokollstratégiájáról

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.