Villanyszerelők Lapja

Zöld oldal

OCPP kommunikációs protokoll 2.0

Elektromosautó-töltőállomások

2018. június 18. | Kozma László |  97 | |

OCPP kommunikációs protokoll 2.0

Múlt havi cikkünkben alaposan körüljártuk az OCPP kommunikációs protokollt, amely az elektromosautó-töltőállomások és az azokat kiszolgáló back-end számítógépes szoftverrendszer közötti nyelvet írja le. Akkor a leginkább elterjedt és a legtöbb gyártó által használt 1.5 és 1.6 verziók részleteit írtuk le, azonban időközben megjelent a legújabb, 2.0 változat. Hamarosan minden gyártó át fog állni erre, ezért érdemes megnézni az újdonságokat, fejlesztéseket és a változásokat.

Hol tart az OCPP jelenleg

Ahogy azt az előző cikkben is lehetett olvasni, a gyártók (szoftver- és töltőállomás-gyártók egyaránt) az 1.5 és 1.6 verziókat használják jelenleg. A két protokoll nagyjából azonos, az 1.6 verzióban kis módosítások történtek. Arról is írtunk, hogy az OCPP 2.0 verzió az 1.5 verzióra épül és annak alapvető funkcióit megtartja, de további funkciókkal egészül ki a kommunikáció hatékonyságának növelése érdekében (kevesebb kommunikáció, kisebb adatforgalom, kevesebb költség), amelyben az árak átadása és az intelligens díjszámítások is megjelennek, valamint a töltőállomásokat is könnyebben lehet távolról felügyelni.

Mi az OCPP?

Az OCPP egy rövidítés. Mint ahogy azt a műszaki és technikai, valamint IT világában manapság megszokhattuk, ez a kifejezés is az angol nyelvből került rövidítésre és azóta is így hivatkozik rá jelenleg mindenki az elektromosautó-, valamint elektromosautó-töltőállomás iparágban. OCPP=Open Charge Point Protocol, azaz tulajdonképp a töltőállomások nyílt, szabadon rendelkezésre álló kommunikációs protokollja. Ismételjünk át még egy rövidítést, az OCA-t (Open Charge Alliance), amely az elektromos járművek és töltőállomások gyártóinak szövetsége, amely az OCPP protokollt gondozza, fejleszti.

A 2.0 változat már 2014 decemberében megjelent vázlataiban, akkor még csak tesztelésre és a tagok által összegyűjtendő igények és információk céljából. A publikálást március elejére ígérték, de egy kis csúszással csak áprilisban jelent meg. Most viszont már elérhető, bárki által letölthető és használható, a gyártók pedig nyilvánvalóan már 2015 eleje óta dolgoznak folyamatosan a termékeik fejlesztésein, és hamarosan megjelentetik az új készülékszoftvereiket (firmware), amelyekben a 2.0-ás tulajdonságok megjelennek. A töltőállomások esetében ezek sokszor egy egyszerű firmware-frissítést igényelnek, természetesen csak akkor, ha a változások nem követelik meg bizonyos hardverelemek jelenlétét.

OCPP 2.0 nagyvonalakban

Készülékek kezelése

Ezt a régóta várt változtatást az olyan töltőállomás-üzemeltetők fogják örömmel venni, akik sok állomást üzemeltetnek, ráadásul ezek az állomások több beszállítótól vagy gyártótól származnak. Az új tulajdonság segít a töltőállomásokat felügyelni, azokat beállítani és a konfigurációkat kiolvasni, vagyis fejlettebb eszközkezelést tesz lehetővé. Ez az újítás segíti az üzemeltetőket abban is, hogy olcsóbban üzemeltessék a rendszereiket, mert a következő funkciókat javítja: leltárjelentések, fejlesztett hiba- és állapotjelentések, fejlesztett konfiguráció és testre szabható felügyelet.

Fejlesztett tranzakciókezelés

A töltőállomás-üzemeltetők másik nagy kívánalma a sok tranzakció kezelése, a töltések utáni számlázások egyszerűsítése, ez a pont ebben segít. Az új 2.0 verzió egységesítette a tranzakcióutasítások struktúráját. A korábbi 1.x verziókban a tranzakcióadatok külön üzenetben voltak szétosztva (tranzakcióindítás, leállítás, mérési érték és állapotértesítés). A megújulás abban áll, hogy ezeket az üzeneteket felválja egy tranzakcióesemény üzenet. Ezzel is csökkenthető a mobil-adatforgalom, amely az üzemeltetés költségeit csökkenti végeredményben. Az adatokat a 2.0-ban tömörítik is, mégpedig WebSocket Compression módszerrel, ezzel is kevesebb lesz a forgalmazott adatmennyiség.

Biztonság

A biztonságos készülékszoftver (firmware) frissítés mindig kritikus, hiszen ha nem fut megfelelő szoftver a töltőállomáson, akkor annak üzemeltetése hiányt szenvedhet, és a tulajdonosnak nem tud pénzt termelni. Ugyanilyen fontos a biztonságos naplózás és az eseményekről való értesítések is. A biztonságos azonosítás és kommunikáció (TSL) is fejlesztésre került az új változatban. Az új protokoll a TSL titkosítást használja, amely széles körben alkalmazott technológia az internetes világban. A titkosítás célja, hogy az interneten keresztül küldött információ ne legyen lehallgatható, illetve hamisítható, vagyis mindig az az adat menjen át, amit a küldő fél küldött és azt csak a fogadó tudja olvasni, senki más. Az új verzió bevezet egy 3 szintű azonosítást is, így még biztonságosabbá és a kibertámadások ellen védettebbé válik az új rendszer.

Okostöltési funkciók

Energiamenedzsment-rendszerrel rendelkező hálózatok esetében az okostöltési funkcióval rendelkező elektromos autók képesek lesznek használni ezt a funkciót. A töltőállomás és a töltőállomás-menedzsmentrendszer képes lesz kezelni bizonyos túlterhelési, időszakos és egyéb szempontok szerinti töltésszabályozást. Így lesznek olyan időszakok, amikor nem lehet majd nagy teljesítményt levenni a töltőről, illetve meg fog valósulni hamarosan a visszatöltés is (V2G – vehicle to grid), vagyis az elektromos autókat villamosenergia-tárolásra is lehet majd használni, nem csak közlekedésre.

ISO 15118 támogatás

Az okostöltési funkciókat az ISO 15118 szabvány foglalja magában. Ebben írnak a töltés olyan formán való megvalósításáról, ahol az autó tulajdonosának nem kell majd magát azonosítania semmilyen OCPP 2.0-át futtató töltőállomáson, ha olyan autóval rendelkezik, amely szintén kezeli az OCPP 2.0-át. Ebben az esetben ugyanis már az autó fogja tartalmazni a tulajdonos adatait, és az azonosítás a töltőben megtörténik az autó felcsatlakoztatásával (név, cím, bankszámlaadatok, számlázás…). Nem kell majd applikációkban engedélyt kérni vagy RFID-kártyákat hordozni.

Kijelzés és üzenetek támogatása

Ez a pont az autó tulajdonosa számára lesz fontos, mert segít abban, hogy érthetőbb és könnyebben áttekinthető üzeneteket kapjon a töltőn való kijelzés során. Itt elsősorban a tarifák, töltési időtartamok, díjak témákra kell gondolni. Az autós már a töltés megkezdése előtt értesülhet a kijelzőn arról, hogy mennyibe kerül az adott pillanatban a töltés, így dönthet a töltés indításáról vagy kereshet másik állomást. De meg tudja majd mutatni azt is, hogy mennyibe kerül egy adott időpontban az összes eddigi töltés, mindezt a töltés közben, vagyis az autó tulajdonosa dönthet a töltés leállításáról még a teljes feltöltés vége előtt, ha a költségek túl magasak lennének számára. A töltés befejezésekor pedig láthatja a teljes tranzakciót és a végösszeget is.

Az 1.x verziók leginkább az RFID-kártyahasználatot támogatta, abban az időben az volt a legolcsóbb és legfejlettebb autentikációs lehetőség egy töltőállomás számára. Az új változat már támogatja az ISO 15118 által leírt Plug & Charge azonosítást, a fizetőterminálokat, az okostelefonos megoldásokat. De ebben a pontban valósította meg azt is a protokollfejlesztő, hogy a töltőállomás érzékelje az autón keresztül, melyik az autótulajdonos számára preferált nyelv (például az autóban beállított nyelv), így az üzeneteket is már ezen a nyelven lesz képes a kijelzőre írni a töltőállomás, bármilyen beállítás vagy kiválasztás nélkül.

Elektromosautó-töltőállomás üzembe helyezése tesztbőrönddel

Sok más javítás, amelyeket az EV-töltéssel foglalkozó közösség javasolt

Az OCA-tagok arról döntöttek, hogy az előző cikkben bemutatott SOAP protokollt nem használják többet és áttérnek a Json (OCPP-J) protokollra. Változtattak bizonyos félreérthető vagy zavart okozó üzenetneveken is. Egy példa erre: RemoteStartTransactionRequest – Távoli indítás tranzakciókérés.

Sok alkalmazó azt gondolta, ennek az üzenetnek a jelentése az, hogy a töltőállomásnak el kellene indítania a tranzakciót. Valójában ez azt jelente, hogy a töltőállomás csak próbálja meg elindítani a tranzakciót, de például, ha nincs kábel bedugva az állomásba, akkor nem indítható el a töltési tranzakció. Ezért egy logikusabb nevet választottak: RequestStartTransactionRequest – Indításkérés, tranzakciókérés.

Látható, hogy az új verzió modern és jövőbe tekintő változat, amely sok hasznos újítást tartalmaz az üzletág minden résztvevője számára. Azt azonban érdemes megemlíteni, hogy a back-end szoftvereket gyártó cégek még nem igazán érték utol ezeket a fejlesztéseket. Döntő többségük még most is csak az OCPP1.5 verzióval kompatibilis, és nem fejlesztette le szoftverében az 1.6-os változásokat sem, így gyors átállás a 2.0-ra egyelőre nem várható.

E-mobilitáse-töltőElektromos autó