OCPP 1.6 vs 2.0.1 vs 2.1: melyiket válasszuk DC töltőparkhoz az AFIR miatt?

Forrás: Open Charge Alliance – AFIR & OCPP (2024. január); Arthur Cox (2024. április 12.)

Egy DC töltőpark beszerzésekor a legtöbb beruházó a kW-ra, a csatlakozóra és az árra figyel. Pedig a töltő „agya”, vagyis az a protokoll, amellyel a háttérrendszerrel (CSMS) beszél, legalább annyira meghatározza a következő tíz évet. Ha a protokoll vagy a háttérrendszer rosszul sikerül, az AFIR-kötelezettségeket (fizetés, árkijelzés, adatszolgáltatás) utólag, drágán kell pótolni. Ez az útmutató az OCPP 1.6, 2.0.1 és 2.1 közti különbségeket veszi sorra DC gyorstöltő szemszögből, magyar kútüzemeltetőknek, flottáknak és önkormányzatoknak.

Mi az OCPP, és miért több puszta technikai részletnél?

Az OCPP (Open Charge Point Protocol) a töltőállomás és a központi háttérrendszer közös nyelve. Ezen keresztül indul és áll le a töltés, ezen jön az energiamérő adat, a hibajelzés, a firmware-frissítés, és ezen érkezik a teljesítménykorlát is. Az általános alapokat a OCPP-ról szóló alapcikkünk tartalmazza; itt a DC-specifikus döntésre koncentrálunk.

DC-nél azért kritikus, mert egy 150–400 kW-os egység sokszorosa egy AC-pontnak, és a bevétel is rajta keresztül folyik. Ha a töltő nem tud rendesen kommunikálni, az nem „kényelmi hiba”: áll a kassza.

Mit mond az AFIR az OCPP-ről – és mit nem?

Fontos tisztázni: az AFIR (az EU (2023/1804) rendelete) nem ír elő konkrét OCPP-verziót. Az Open Charge Alliance elemzése szerint mind az 1.6-os, mind a 2.0.1-es verzióra épülő állomás megfelelhet, az ad hoc fizetéshez azonban kisebb egyedi kiegészítés kell. A rendelet a funkciókat és az időpontokat szabja meg. A forrásokban szereplő főbb mérföldkövek:

• 2024. április 13. – a rendelet alkalmazandó; az ad hoc töltésnek regisztráció és szerződés nélkül elérhetőnek kell lennie.
• 2024. október 14. – minden nyilvánosan hozzáférhető töltőpontnak digitálisan csatlakoznia kell; az új vagy felújított pontoknak okos töltésre alkalmasnak kell lenniük.
• 2025. április 14. – a nyilvános DC pontokon rögzített töltőkábel kötelező.
• 2027. január 1. – az 50 kW feletti, TEN-T úthálózaton vagy biztonságos parkolóban lévő pontoknak a kártyaolvasós (érintésmentes) fizetést is tudniuk kell (Arthur Cox összefoglalója szerint).

OCPP 1.6: a bevált, de kiegészítésre szoruló munkaló

Az 1.6 a legelterjedtebb verzió, szinte minden háttérrendszer és roaming-platform ismeri. Az okos töltés (teljesítménykorlátozás profilokkal) natívan benne van, így a hálózati csúcs kezelése és a dinamikus terheléselosztás megoldható vele. A hiányosságok éppen az AFIR-hez kapcsolódó részeknél jelentkeznek:

• az ad hoc kártyás fizetéshez nincs szabványos üzenet, jellemzően egyedi (DataTransfer) megoldás kell;
• az ár megjelenítése a töltő kijelzőjén OCA-féle kiegészítést igényel;
• a biztonsági funkciók (tanúsítványkezelés) az alapverzióban szerények.

Következmény: egy 1.6-os töltőpark működhet és megfelelhet, de a „megfelelés” itt gyakran a gyártó és a háttérrendszer-szolgáltató egyedi összehangolásán múlik. Ez később cserénél, szolgáltatóváltásnál okozhat fejfájást.

OCPP 2.0.1: a mai beszerzések alapértelmezett célpontja

A 2.0.1 a töltő és a háttérrendszer viszonyát részletesebben szabályozza: eszközmodell (a töltő minden részegysége külön menedzselhető), jobb hibadiagnosztika, bővített biztonság és az ISO 15118 alapú Plug & Charge támogatása. Az árakhoz használható a SetDisplayMessage üzenet, így a kijelzőn megjeleníthető az AFIR által elvárt kWh-ár. A költségszámítás továbbra is jellemzően a háttérrendszerben fut, a helyi számításhoz kiegészítés kell (OCA white paper).

A 2.0.1 igazi előnye a tanúsítványalapú azonosítás. Az autó és a töltő digitális tanúsítvánnyal igazolja magát, a számlázás a háttérrendszeren és a roaming-partneren át történik. A témát külön cikkben részleteztük: ISO 15118-20 és Plug & Charge DC töltőn. Gyakorlati tanulság: Plug & Charge csak akkor működik, ha a töltő, a háttérrendszer és a roaming-lánc is tudja. Egyetlen gyenge láncszem miatt az autós továbbra is kártyát vagy appot használ.

OCPP 2.1: mit hozott, és kell-e rá várni?

Az OCA szerint a 2.1-es specifikáció az AFIR-hez kapcsolódó funkciókat natívan kezeli: szabványosított fizetési terminál-adatcsere, tarifa-modellek a helyi költségszámításhoz és kétirányú (V2X) töltés. Ez papíron a legtisztább megoldás. A gyakorlati kérdés viszont nem az, mit tud a szabvány, hanem hogy a töltő gyártója, a háttérrendszer és a roaming-partnerek közül ki támogatja már éles, tanúsított formában.

Ésszerű megközelítés: ne a verziószám alapján dönts, hanem kérj írásos vállalást a firmware-frissíthetőségről. Egy jól tervezett DC töltő távolról (OTA) frissíthető, így a későbbi verzióváltás nem hardvercsere.

Összehasonlító táblázat: OCPP 1.6 vs 2.0.1 vs 2.1

A táblázat első öt sora az Open Charge Alliance összehasonlításán alapul, az utolsó két sor saját szakmai értékelésünk.

Az ad hoc fizetés a gyakorlatban: terminál, ár, nyugta

Az AFIR szerint az 50 kW feletti pontoknál az ad hoc árat kWh alapon kell megadni, opcionálisan percdíjas (idle fee) elemmel, és ezt a töltő kijelzőjén meg kell mutatni. Az árelemek sorrendje: kWh-díj, percdíj, munkamenet-díj, egyéb. A fizetési terminál egy telephelyen több töltőt is kiszolgálhat.

A protokoll itt válik kézzelfoghatóvá: a kijelzőn lévő ár, a terminál és az app árának egyeznie kell. Ha három csatorna három különböző adatforrásból dolgozik, az átláthatósági hibát és panaszt szül. Ezért ne a terminált és a háttérrendszert külön szállítóktól, külön árlistával vegye meg, hanem kérje, hogy egyetlen árforrásból frissüljön minden felület. Az árakról és a javasolt átláthatósági szabályokról lásd a AFIR-felülvizsgálatról szóló cikkünket.

Hiteles mérés és adatszolgáltatás: az OCPP mögötti láthatatlan réteg

A kWh-alapú elszámoláshoz a mérés legyen hiteles (MID / Eichrecht jelleg), és az adatnak el kell jutnia a háttérrendszerhez és a számlához. Az AFIR a statikus (hely, csatlakozó, teljesítmény) és dinamikus (állapot, elérhetőség, ár) adatok API-n át történő szolgáltatását is kéri, nemzeti hozzáférési pontokra. A mérési oldalról részletesen írtunk: hiteles kWh-mérés DC töltőn.

A gyakorlati tanulság: az OCPP-verzió mellett azt is kérdezze meg, milyen formátumban adja a rendszer a mérési adatot, és hogyan exportálható az adat roaming-partnernek vagy a hatóságnak.

Mit tud az eJoin portfólió OCPP-ből?

A GreenTech Invest az eJoin (EVsolution s.r.o.) magyarországi forgalmazója. A gyártói katalógus szerint a termékek OCPP-támogatása családonként eltér, ezért ezt érdemes beszerzés előtt írásban rögzíteni:

A katalógusadatok a gyártó 2025/09-es árlistáján alapulnak; a pontos, megrendelt konfiguráció verziótámogatását (és a 2.0.1/2.1-re frissíthetőséget) ajánlatadáskor írásban visszaigazoljuk. A gyártói oldalon a Rapid sorozat 60–400 kW-os, a Rapid Terminal 160–600 kW-os tartományban szerepel, a fizetési terminált (bankkártya, mobil, NFC) a termékoldal funkcióként említi. Gyártói referenciaként az eJoin Szlovákia második legnagyobb töltőhálózatának tekinti magát (ejoin.eu); ez nem a ChargeIt saját telepítése.

Háttérrendszer (CSMS) választás: ne a töltő mögött kapkodjon

A háttérrendszer általában hosszabb életű döntés, mint a hardver. Néhány szempont, amit érdemes megkövetelni:

• támogatja az OCPP 1.6-ot és a 2.0.1-et egyszerre, hogy vegyes parkot is kezeljen;
• OCPI-roaming, terminálintegráció és egységes árkezelés;
• az adatai exportálhatók, nincs zárt adatcsapda;
• dinamikus terheléselosztás (DLM) kezelése, hogy a lekötött kapacitás ne lépődjön túl.

Az eJoin saját Smart Fuel Pass háttérrendszere listaáron 8 €/csatlakozó/hó (ÁFA nélkül); a hálózati teljesítményszabályozáshoz a Grid Guard 990 €-tól elérhető. A részleteket a DC töltő szoftver és DLM oldalon találja.

Illusztratív példa: 6 töltőpontos kútpark, két út a szoftverig

Egy képzeletbeli, TEN-T közelében lévő benzinkút 3 db kétcsatlakozós, 150 kW-os DC töltőt (6 töltőpontot) telepít. Két terv készül:

A terv: olcsó 1.6-os töltők, külön vásárolt fizetési terminál, külön app. Három felület, három árforrás. Évek múlva a háttérrendszer-szolgáltató megszűnik, a töltők adata nem exportálható, a váltás helyszíni munkát igényel.

B terv: OTA-frissíthető, 2.0.1-képes töltők, egységes árforrású háttérrendszer, a fizetési terminál a töltőcsaládba integrálva (az All-in-One-hoz beépített terminál opcióként +1 170 € listaáron), hiteles DC-mérés opcióval. Kezdetben többe kerül, de szolgáltatóváltás és protokollfrissítés szoftveres feladat.

A tanulság nem az, hogy a B terv mindig olcsóbb, hanem hogy a protokoll, a terminál és a háttérrendszer együtt tervezendő.

Gyakori hibák OCPP-vel kapcsolatban

• Verziószámra vadászás funkció helyett. A „2.0.1-es” felirat önmagában semmit nem garantál; a konkrét funkciókat kérdezze.
• Zárt, egy gyártóhoz kötött háttérrendszer. Később minden váltás hardvercserét jelent.
• A fizetési terminál utólagos kezelése. A terminál illesztése az ár- és számlaadatokhoz nem „dugd be” feladat.
• Az adatszolgáltatás elfelejtése. Az AFIR-adatok a nemzeti hozzáférési pontokra tartoznak, ehhez a háttérrendszernek kell tudnia API-t.
• Mobilhálózatra bízott kritikus kapcsolat. Telephelyen mindig legyen vezetékes vagy redundáns kapcsolat.

Döntési ellenőrzőlista beszerzés előtt

1. Melyik OCPP-verziót támogatja a töltő ma, és melyiket vállalja frissítéssel?
2. Hogyan oldja meg az ad hoc fizetést és az ár kijelzését?
3. Hiteles-e a DC-mérés, és exportálható-e az adat?
4. Egyetlen árforrásból frissül-e a kijelző, a terminál és az app?
5. Milyen háttérrendszerekkel és roaming-partnerekkel tanúsított?
6. Kezeli-e a dinamikus terheléselosztást a lekötött kapacitás védelmében?
7. Írásban rögzítették-e a firmware-frissítés feltételeit?

A teljes DC-projekt szempontjaihoz lásd a DC töltőállomás és az AFIR-megfelelés oldalunkat.

Gyakran ismételt kérdések

Kötelező-e az OCPP 2.0.1 az AFIR miatt?

A rendelet nem nevez meg konkrét verziót. Az OCA szerint az 1.6 és a 2.0.1 is megfelelhet kisebb kiegészítéssel az ad hoc fizetésnél. Egyes szolgáltatói anyagok (például a Codibly 2026-os összefoglalója) a 2.0.1-et gyakorlati elvárásnak tekintik, de ez szolgáltatói álláspont, nem jogszabályi előírás.

Cserélni kell a meglévő 1.6-os töltőket?

Nem feltétlenül. Ha a töltő firmware-je frissíthető, és a háttérrendszer kezeli az AFIR-funkciókat (fizetés, ár, adat), az 1.6 is működhet. Egyedi, nehezen karbantartható kiegészítésekre viszont ne építsen hosszú távon.

Mi a különbség az OCPP és az ISO 15118 között?

Az OCPP a töltő és a háttérrendszer közti, az ISO 15118 az autó és a töltő közti kommunikáció. Plug & Charge-hoz mindkettő kell.

Kell-e fizetési terminál minden DC töltőre?

A hatály a teljesítménytől és a helytől függ: 50 kW alatt QR/app is elég lehet, 50 kW felett kártyaolvasós megoldás szükséges, a TEN-T menti meglévő pontokra a források 2027. január 1-jét említik. Egy terminál több töltőt is kiszolgálhat.

Mennyibe kerül a háttérrendszer?

Szolgáltatótól függ. Az eJoin Smart Fuel Pass listaára 8 €/csatlakozó/hó (ÁFA nélkül, 2025/09-es árlista); külső CSMS-nél árazás és szerződés eltér.

Mikor érdemes OCPP 2.1-et kérni?

Ha a töltő, a háttérrendszer és a roaming-partner is támogatja éles, tanúsított formában, vagy ha V2X a cél. Egyébként elég egy 2.0.1-képes, OTA-frissíthető töltő.

Források

• Open Charge Alliance – AFIR & OCPP (2024. január 9.)
• Open Charge Alliance – OCPP and AFIR white paper (v1.0, 2024. január)
• Arthur Cox – Electric vehicle charging: new obligations (2024. április 12.)
• Codibly – EV Charging Regulations in 2026 (2026. április 20.)
• Smappee – AFIR and ISO 15118 explained
• ejoin.eu – gyártói termékoldal