Teljes körű útmutató az OCPP 1.6-tól EV Töltőhálózatok

Oszd meg ezt a cikket a közösségi médiában:

Az elektromos járművek (EV) piaca hatalmas átalakuláson megy keresztül, mivel már nem réspiac, hanem világszerte elterjedt infrastrukturális követelmény. EV járművezetők. SEO üzemeltetőként vagy töltőállomás-üzemeltetőként hamarosan rájössz, hogy a hardverek, mint például EV töltők csak a siker fele. A töltőhálózat igazi okossága abban rejlik, EV töltési protokoll. Itt az Open Charge Point Protocol (OCPP) 1.6 igazi nyílt kommunikációs szabványként jelenik meg. Közös nyelvként szolgál – az eszperantóként. EV töltés – amely lehetővé teszi, hogy az egyik gyártó hardverei zökkenőmentesen, problémamentesen kommunikáljanak más felügyeleti platformokkal és különböző rendszerekkel. Az iparág különben saját fejlesztésű rendszerekből álló összeállítás lenne, amelyek nem tudnak együttműködni egymással, globális szabvány nélkül, így rémálom lenne a karbantartásuk és a skálázásuk.

OCPP1

Mi is pontosan az OCPP 1.6?

Alapvetően az OCPP 1.6 egy nyílt forráskódú kommunikációs protokoll, amelyet az Open Charge Alliance (OCA) kezel, egy globális konzorcium, amely a fejlesztésre törekszik. EV infrastruktúra. Meghatározza az információcsere protokolljait egy EV Töltőállomás (a Charge Point) és egy központi rendszer vagy háttérirodai rendszer. Az OCPP korábbi verzióival ellentétben az 1.6-os verzió néhány olyan kulcsfontosságú funkcióval bővült, amelyek szabványosították a hálózaton belüli adatkezelést.

Az OCPP 1.6 alapvető funkciói a töltési folyamat életciklusát hivatottak lefedni. A töltő kezdeti bekapcsolásakor egy BootNotification üzenetet küld a CMS-nek, hogy azonosítsa magát és a hardver specifikációit. A töltő rendszeresen Heartbeat üzenetet küld az online maradáshoz. A felhasználó érkezésekor a protokoll az RFID-címkék vagy mobilalkalmazás-hitelesítő adatok adatbázissal való összehasonlításával kezeli az engedélyezést. A töltő a töltési folyamat során MeterValues ​​értékeket küld az energiafogyasztás jelentésére, ami elengedhetetlen a számlázáshoz. Végül a protokoll támogatja a távoli parancsokat, beleértve a RemoteStartTransaction vagy a RemoteStopTransaction parancsot, így a kezelők több ezer kilométer távolságból is működtethetik a hardvert anélkül, hogy fizikailag jelen lennének. Ezen tranzakciós alapokon túl az OCPP 1.6 támogatja a firmware online frissítéseket (OTA). Ez lehetővé teszi a kezelők számára, hogy távolról telepítsenek szoftverjavításokat, biztonsági frissítéseket és új funkciókat a hardverre, így a ma telepített töltő kompatibilis lesz a holnap elektromos járműveivel anélkül, hogy technikusnak kellene a helyszínre látogatnia.

Miért váltotta fel az OCPP 1.6 JSON a régebbi SOAP verziót?

A korai időszakban EV Az infrastruktúra miatt sok gyártó saját protokollokat alkalmazott. Amikor töltőt vásároltál az A vállalatnál, nem volt más választásod, mint az A vállalat szoftverét használni, amíg a termék kitartott. Ez a szállítói kötöttség nagy veszélyt jelentett az üzemeltetőkre. Abban az esetben, ha a gyártó csődbe ment volna, vagy megemelte volna a szoftverárakat, a hardver drága papírnehezékké vált.

Az OCPP 1.6 ezt a kockázatot az interoperabilitás biztosításával kerüli el. Egy EPC (mérnöki, beszerzési és kivitelezési) vállalkozó kiválaszthatja a legstabilabb hardvert, és azt kombinálhatja bármely OCPP-kompatibilis szoftverrel, amely biztosítja a szükséges számlázási és felügyeleti képességeket. Ez a rugalmasság ösztönzi a versenyt és az innovációt. Ezenkívül megkönnyíti a töltőhálózatok bővítésének folyamatát. Egy üzemeltető nem korlátozódik egyetlen márkára, amikor új állomásokat szeretne hozzáadni egy meglévő helyszínhez. A helyi igényeknek megfelelően kombinálhatják és cserélhetik a berendezéseket, és továbbra is egyetlen kezelőfelülettel rendelkezhetnek.

Az ok, amiért az OCPP 1.6 JSON felváltotta a régebbi SOAP verziót

A technológiai fejlődés nem feltétlenül a funkciók hozzáadását jelenti, hanem a kézbesítési mechanizmus fejlesztését. Az OCPP 1.6 előtt a protokoll SOAP-ot (Simple Object Access Protocol) használt, amely XML-alapú üzenetküldést biztosított. A SOAP funkcionális volt, de nehézkes, és az XML bőbeszédű jellege miatt sok sávszélességet és feldolgozási teljesítményt fogyasztott.

Az iparágat megváltoztatta az OCPP 1.6 JSON-ra (JavaScript Object Notation) való áttérés a WebSockets-ről. A JSON egy könnyű adatcsere-formátum, amelyet sokkal egyszerűbb gépeknek és embereknek olvasni. A protokoll a JSON használatával elérte a legfontosabb célok némelyikét. Először is, jelentősen javította az adatátvitel hatékonyságát, ami kulcsfontosságú a mobilhálózatokon keresztül összekapcsolt töltőknél, ahol minden megabájt pénz. Másodszor, csökkentette a késleltetést, ami lehetővé tette a szinte valós idejű kommunikációt a töltő és a felügyeleti rendszer között. Végül maximalizálta a rendszer skálázhatóságát, lehetővé téve egyetlen felhőszerver számára, hogy egyszerre több tízezer töltőt kezeljen anélkül, hogy a nehéz XML-feldolgozás terhelése alatt összeomlana.

A JSON keretrendszer technikai fölénye azonnal nyilvánvaló a hagyományos SOAP architektúrával szemben a működés számos kulcsfontosságú dimenziójában:

Metric SOAP (Régebbi) JSON (OCPP 1.6J)
Üzenet mérete Nagy (nehéz XML fejlécek) Kicsi (hatékony kulcs-érték párok)
Sávszélesség használata Magas (drága a 4G/5G SIM-kártyáknál) Alacsony (mobil IoT-re optimalizálva)
Kommunikáció Csak kérésre-válaszra Teljes duplex (WebSockets)
Bővíthetőség Nehéz nagy hálózatok számára Magas (alacsony szerver terhelés)
Könnyű hibakeresés Bonyolult Egyszerű

Az intelligens töltés és a dinamikus terheléselosztás mechanikája az OCPP 1.6 segítségével

OCPP2

OCPP 1.6 transzformációk EV A töltést passzív energiaellátássá alakítja, majd aktív energia-vezérelttá. Alapvető innovációja, az Intelligens Töltés lehetővé teszi az üzemeltetők számára, hogy elkerüljék a költséges hálózati fejlesztéseket azáltal, hogy az egyes töltőket egységes, szoftveresen vezérelt hálózattá alakítja, és jelentősen megnöveli az aktív töltőpontok számát.

A központi felügyeleti rendszer (CMS) már nem pusztán figyeli az adatokat, hanem aktívan szabályozza a hardver elektromos viselkedését a töltési profilok használatával. Ez a részletes vezérlés teszi lehetővé a dinamikus terheléselosztást (DLB) egy kereskedelmi valóság:

  • Az infrastruktúra kapacitásának optimalizálása: Dinamikus terheléselosztás (DLB) a fizikai korlátokat változókká alakítja. Az OCPP 1.6 tíz vagy több töltőt is képes biztonságosan támogatni a hagyományos 100 kW-os korláttal ellentétben. A rendszer valós időben méri a teljes terhelést, és automatikusan csökkenti az egységenkénti teljesítményt a hálózat stabilitásának megőrzése és az aktív töltőpontok számának maximalizálása érdekében.
  • Intelligens prioritáskezelés: Az operátorok túlmutatnak az egyszerű elosztáson olyan funkciókkal, mint a StackLevel és a Charging Schedules. Elsőbbséget adhatnak a prémium előfizetőknek vagy a flotta járműveinek, hogy azok készen álljanak a bevetésre, és más munkamenetek használják fel a fennmaradó energiapuffert.
  • Algoritmikus költségoptimalizálás: A rendszer automatikusan a felhasználási időhöz (TOU) igazítja a töltési sebességet, a nagy fogyasztást a csúcsidőn kívüli időszakra helyezve át, így jelentősen csökkentve az áramköltségeket és maximalizálva a haszonkulcsot.

Digitális protokollok lefordítása valós idejű hardveres érzékelőmonitorozássá

Egy protokoll egyszerűen utasítások sorozata; megfelelő hardverre van szükség ahhoz, hogy ezeket az utasításokat fizikai cselekvésekké alakítsa. Tekintsük a protokollt és a hardvert az agynak és az idegrendszernek. Amikor a CMS parancsot ad ki a tranzakció leállítására, a töltő belső vezérlőjének aktiválnia kell egy fizikai kontaktort az elektromos kapcsolat megszakításához.

Az OCPP 1.6 közvetlenül kommunikál a különböző hardverérzékelőkkel a biztonság és a pontosság biztosítása érdekében. Például a MeterValues ​​üzenet a töltőn belüli nagy felbontású áram- és feszültségérzékelőkön alapul. Ha ezek az érzékelők nincsenek megfelelően kalibrálva, az OCPP-n keresztül továbbított számlázási információk helytelenek lesznek. Ezenkívül a protokoll nyomon követi a hőmérséklet-érzékelőket is. Amikor a belső alkatrészek egyike túlmelegedni kezd, a töltő hibás állapotjelzést küldhet, és a szoftver leállíthatja a munkamenetet, mielőtt a töltő megsérülhetne.

Kifinomultabb hardvereknél, mint például a PCT szabadalmaztatott ívoltó struktúrák esetén az interakció még kritikusabb. A fizikai védelmet (IP66 szigetelés, 1500 V DC leválasztás) a hardver biztosítja, az OCPP protokoll pedig a diagnosztikai réteget, amely tájékoztatja a kezelőt ezen alkatrészek állapotáról. Ez a szinergia biztosítja, hogy a biztonság fogalma ne passzív funkció legyen, hanem aktívan felügyelt adatpont. A nyers hardver és a pontos digitális szabványok tökéletes keverékének biztosításában rejlik a... BENY jön be a gyártási tapasztalat.

Hogyan BENY A hardver maximalizálja az OCPP 1.6 megbízhatóságát és biztonságát?

Az OCPP 1.6 maximális eléréséhez olyan hardvert kell használni, amely tökéletesen képes komplex digitális parancsok végrehajtására. BENY több mint 30 éves gyártási tapasztalattal rendelkezik, és teljes mértékben vertikálisan integrált, beleértve a R&D az automatizált összeszereléshez, hogy biztosítsa EV Teljesen megbízható töltési megoldások.
Intelligens energiagazdálkodás
Ennek az integrációnak a lelke a saját fejlesztésű, teljes körűen tanúsított EVsaas platform. Zökkenőmentes CMS-interoperabilitást biztosít az OCPP 1.6J-n keresztül, amely lehetővé teszi a távoli OTA frissítéseket, a nyitott fedél észlelését és a pontos ütemezett töltést. Ezt a szoftveres intelligenciát kifinomult energia-vezérelt rendszer egészíti ki, beépített dinamikus terheléselosztással (DLB), amely könnyen integrálható napelemes rendszerekkel PV rendszerek a hálózat kihasználtságának maximalizálása érdekében.
🛡️
Kompromisszumok nélküli fizikai biztonság
Ami még fontosabb, BENY biztosítja, hogy ezeket a dinamikus teljesítményváltozásokat kompromisszumok nélküli fizikai biztonság támogassa. A töltők UL-tanúsítvánnyal rendelkező, lángálló PC és ABS keverékekből készülnek, PCT-szabadalmaztatott ívoltó szerkezet. Hiba esetén a rendszer automatikusan leválasztja az összes pólust, beleértve a földelővezetőt is. 3 év garancia, gyors reagálású műszaki támogatás és átfogó nemzetközi tanúsítványok, mint például az UL, CE és TUV támogatják. BENY robusztus, intelligens hardveralapot kínál, amelyre az intelligens töltőhálózata szüksége van.

Kapcsolatfelvétel az OCPP-tanúsítvánnyal rendelkező töltési megoldásokkal kapcsolatban

OCPP3

Gyakori csatlakozási hibák és azok gyors javítása

A legmegfelelőbb hardver ellenére is nehéz lehet töltőállomást telepíteni. Egy új töltő és egy CMS közötti digitális kézfogás számos okból kifolyólag sikertelen lehet. Az öt leggyakoribb csatlakozási hiba és azok megoldásai a következők:

  • Helytelen WebSocket URL (OCPP végpont): A leggyakoribb hiba a CMS URL-címben lévő elírás, azaz a töltő nem tudja, hová küldje az üzeneteit. Ennek megoldásához győződjön meg arról, hogy a végpont címe (általában wss:// vagy wss:// előtaggal kezdődik) helyes, és hogy az URL végén található töltési pont azonosítója pontosan megegyezik a háttérszoftverben regisztrált azonosítóval.
  • Hálózati és tűzfalkorlátozások: Számos ipari vagy kereskedelmi telepítés használ hardveres tűzfalakat, amelyek megakadályozzák a WebSockets használatához szükséges portokat. Ez a probléma a telephely informatikai részlegével együttműködve orvosolható, és biztosítható, hogy a helyi hálózat engedélyezze a kimenő forgalmat a szükséges portokon (általában a 80-as vagy a 443-as porton), és hogy a CMS IP-címe sikeresen felkerült az engedélyezőlistára.
  • SSL/TLS tanúsítvány eltérés: Biztonságos kapcsolat (wss://) esetén a töltőnek alapértelmezés szerint meg kell bíznia a szerverben az SSL-tanúsítványán keresztül. Mivel a régebbi firmware-ek nem biztos, hogy képesek azonosítani az újabb tanúsítványokat, a leghatékonyabb módszer a töltő firmware-jének frissítése a legújabb verzióra, vagy annak biztosítása, hogy a CMS globálisan elfogadott hitelesítésszolgáltatót használjon.
  • Engedélyezési hibák (offline mód): Előfordulhat, hogy egy töltő csatlakozni tud a hálózathoz, de nem kezdi meg a töltési folyamatot. Ez általában sérült helyi hitelesítési listára vagy gyorsítótárra utal. Ezt általában a töltő helyi gyorsítótárának közvetlenül a CMS-en keresztüli törlésével, valamint az AuthorizeRemoteTxRequests paraméter megfelelő beállításának ellenőrzésével lehet megszüntetni.
  • Paraméterkonfigurációs hibák: Az OCPP 1.6 több száz konfigurációs kulccsal rendelkezik, beleértve a HeartbeatInterval vagy a MeterValueSampleInterval kulcsokat is. Ha ezek bármelyikét olyan értékre állítják be, amelyet a hardver fizikailag nem képes fenntartani, a kapcsolat valószínűleg megszakad. A Hard Reset visszaállítja a töltő gyári OCPP beállításait, és a kulcsokat biztonságosan újrakonfigurálhatja egyenként.

OCPP 1.6 vs 2.0.1: Melyiket használjam most?

Az iparág fejlődésével a vita az OCPP 2.0.1-re terelődött. A legtöbb meglévő projekt esetében azonban az 1.6-os verzió az iparág svájci bicskája, megbízható, sokoldalú és sokan támogatják.

A következőkben a két verzió közvetlen összehasonlítását láthatjuk a főbb műszaki és működési szempontok alapján:

Összehasonlítási dimenzió OCPP 1.6 OCPP 2.0.1
Piaci örökbefogadás Rendkívül magas (>90%) Feltörekvő (növekvő)
Biztonsági tervezés Alap (kiegészítő TLS) Natív (biztonságos tervezés)
Device Management Korlátozott Speciális (gazdag diagnosztika)
Intelligens töltés Érett (töltési profilok) Továbbfejlesztett (külső bemenetek)
Plug & Charge Nem (kivéve, ha testreszabott) Natív (ISO 15118 támogatás)
Visszafelé kompatibilitás N / A Korlátozott (híd szükséges)

Az OCPP 1.6 vitathatatlan piacvezető a kereskedelmi telepítés és piaci részesedés terén világszerte. Páratlan ökoszisztéma-érettséggel rendelkezik, amely gyors és alacsony költségű integrációt biztosít gyakorlatilag bármilyen meglévő hardverrel vagy központi felügyeleti rendszerrel (CMS), és az iparág praktikus, csatában bevált munkalova. Másrészt az OCPP 2.0.1-et a mai nagy igényű hálózatok támogatására tervezték. Egyedülálló előnyöket kínál a legmodernebb kriptográfiai biztonságban, natív végponttól végpontig tartó tanúsítványkezeléssel, valamint komplex eszköztopológia-kezeléssel, finomszemcsés távoli diagnosztikával és finomszemcsés helyi energiaútválasztással.

Az OCPP 1.6 ma a legtöbb kereskedelmi és lakossági telepítés esetében a megfelelő választás. Ez a legstabilabb, és szinte az összes CMS a világon támogatja. Ha egy óriási autópálya-töltőállomást építesz, az Ultra-Fast-et, vagy a Plug and Charge (az autó kártya nélkül azonosítja magát) használatát tervezed, akkor jó jövőbiztos lépés befektetni egy 2.0.1-kompatibilis hardverbe.

Szükséges-e a töltődnek hivatalos OCA-tanúsítvány?

Az, hogy a töltő gyártója kijelenti, hogy megfelel az OCPP szabványnak, nem elegendő. A protokollt az Open Charge Alliance (OCA) nem tanúsította hivatalosan, így nincs külső bizonyíték arra, hogy a protokollt helyesen használták. Az OCA tanúsítvány szigorú tesztelés révén biztosítja, hogy a Core és a Smart Charging funkciói hibátlanok legyenek. Ez jelentősen minimalizálja az interoperabilitási kockázatokat az energiaszolgáltatók és a nagybefektetők számára. Azt is biztosítja, hogy a hardver teljesen kompatibilis legyen, még akkor is, ha sok évvel később szoftverszolgáltatót vált, így nem kell sok pénzt költenie átírásra.

A műszaki megbízhatóság mellett a hivatalos OCA-tanúsítvány fontos kereskedelmi erőforrás. Elengedhetetlen azoknak a vállalatoknak, amelyek nemzetközi szinten működnek, vagy kormányzati szerződésekre pályáznak. A legversenyképesebb piacokon, mint például Észak-Amerika, a hivatalos megfelelés igazolása gyakran előfeltétele a jövedelmező kormányzati megbízások megszerzésének. EV infrastruktúra-támogatások. Végül pedig egy kompromisszummentes minőségi jelvény, amely azt bizonyítja, hogy a hardver bankképes, szabványosított és globális piacra kész.

OCPP4

Összegzés

A modern EV A töltési forradalom az OCPP 1.6 láthatatlan keze. Szabványosított, könnyűsúlyú és intelligens kommunikációs keretrendszert kínálva lehetővé tette az infrastruktúra gyors skálázását világszerte. Függetlenül attól, hogy egy kis munkahelyi töltőállomást vagy egy több ezer állomásból álló országos hálózatot üzemeltet, fontos ismerni a protokoll bonyolultságait, beleértve a JSON-ban és az intelligens töltési profilokban való hatékonyságát, hogy sikeresen működhessen.

A töltő hardver kiválasztásakor ne csak a külső burkolatra koncentráljon. Olyan berendezésekre összpontosítson, amelyek a mélyreható DC műszaki ismereteket ötvözik az OCPP erős, tanúsított megvalósításával. Így nemcsak arról gondoskodik, hogy befektetése ne csupán a jelen eszköze legyen, hanem egy skálázható, interoperábilis eszköz, amely a globális energiaátmenet folyamatosan változó igényeihez igazítható.

GYIK

⚡ Mi az OCPP legújabb verziója?
A legújabb hivatalos verzió az OCPP 2.1, amely olyan új funkciókat tartalmaz, mint a kétirányú töltés (V2G), de a kereskedelmi hálózatokban a 2.0.1 és az 1.6 a leggyakrabban használt verziók.

📅 Mikor jelent meg az OCPP 1.6?
Az Open Charge Alliance (OCA) hivatalosan 2015 októberében adta ki az OCPP 1.6-os verzióját.

💰 Ingyenes az OCPP?
Igen, az OCPP egy jogdíjmentes, nyílt protokoll, amelyet bárki letölthet és használhat licencdíj nélkül.

🏢 Mely cégek használják az OCPP-t?
Az OCPP egy nemzetközi iparági szabvány, amelyet szinte minden nagyvállalat használ. EV töltőhardver-gyártók és szoftverhálózat-szolgáltatók, mint például az ABB, a ChargePoint, az Autel, az EVBox és a Driivz.

© 2026 OCPP 1.6 Protokoll Útmutató – Szakmai EV Töltési megoldások

Kap egy ingyenes idézet

Beszéljen Szakértőnkkel

    Beszéljen Szakértőnkkel