RFID-hozzáférés beállítása üzleti elektromosautó-töltőkhöz

Az üzleti elektromosautó-töltők RFID-hozzáférésének beállításához ellenőrizze, hogy az olvasó támogatja-e a használni kívánt azonosítóeszközt, rögzítse a töltő által ténylegesen jelentett azonosítót, regisztrálja ezt az értéket a töltéskezelő platformon, rendelje hozzá a szükséges hozzáférési jogosultságokat, majd tesztelje a teljes töltési folyamatot. Ezután ellenőrizze a működést kapcsolatkimaradáskor és a kártya jogosultságának visszavonásakor is.

A sorozatgyártási tételt csak akkor rendelje meg, ha egy reprezentatív minta sikeresen teljesítette ezt a folyamatot. Egy sikeres kártyaérintés csak az eredmény egy részét igazolja. Az átvételi jegyzőkönyvben a megfelelő töltőpontnak, fióknak, energiaadatnak és leállítási működésnek is szerepelnie kell.

Ez az útmutató a szakképzett telepítő által már telepített és üzembe helyezett töltőberendezések hozzáférés-kezelésével foglalkozik. Annak a csapatnak szól, amely a fizikai azonosítóeszközöket összekapcsolja a töltéskezelő rendszerrel.

Tisztázza, melyik rendszer hozza meg az egyes döntéseket

Online jogosultság-ellenőrzéskor az RFID-olvasó kiolvassa az azonosítót, a töltőállomás továbbítja azt a töltőállomás-kezelő rendszernek, azaz a CSMS-nek, a platform pedig visszaküldi az engedélyezési eredményt. Az OCPP az állomás és a kezelőrendszer közötti kommunikációt szabályozza. A kártya és az olvasó közötti rádiós kapcsolat az integráció külön eleme. Lásd az Open Charge Alliance protokolláttekintését.

Minden rétegnek legyen kijelölt felelőse. A kártyaszállító biztosíthatja a megállapodott fizikai azonosítóeszközt és az azonosítófájlt; a töltőintegrátor igazolja az olvasó működését; a platform üzemeltetője kezeli a fiókregisztrációt és a jogosultságokat. Az üzembe helyezés előtt rögzítsék, ki oldja meg az eltéréseket.

1. Ellenőrizze az olvasó és a jogosultság-ellenőrzés képességeit

Kérje el a pontos töltőmodellhez, hardverváltozathoz és telepített firmware-hez tartozó olvasóspecifikációt. Rögzítse a támogatott érintésmentes szabványokat, az azonosítóeszköz használati módját és az esetleges konfigurálható azonosítókonverziót. Az „RFID-képes” megjelölés ezekre nem ad választ.

Az NFC 13,56 MHz-en működik, és több érintésmentes technológiát foglal magában, köztük az ISO/IEC 14443 Type A, Type B és az ISO/IEC 15693 technológiát. A frekvencia egyezése ezért önmagában nem teljes beszerzési specifikáció. A tényleges kártyatechnológiát és olvasómegvalósítást kell összevetni. Az NFC Forum műszaki áttekintése bemutatja az alapul szolgáló protokollokat.

Ezután tisztázza, mit valósít meg ténylegesen az állomás és a háttérrendszer:

Az OCPP-tanúsítást funkciónként kell értelmezni. Az OCA 2025. decemberi frissítése a Local List Management funkciót az OCPP 2.0.1 Core profil választható elemei közé sorolja. A frissített tanúsítási program tehát nem garantálja, hogy minden tanúsított állomás támogatja a helyi listát. Az OCA OCPP 2.Lite alkalmazási útmutatójának C. szakasza azt is leírja, hogy az engedélyezési gyorsítótár elhagyható, és az egyes megvalósítások eltérő jogosultság-ellenőrzési módszereket támogathatnak.

Kérje el a tanúsítás hatókörét és – ha rendelkezésre áll – a Protocol Implementation Conformance Statement dokumentumot, majd vesse össze ezeket a telepített szoftverrel. Az igazolásokat őrizze a helyszín konfigurációjával együtt.

Az OCA jelenleg OCPP 1.6, 2.0.1 és 2.1 csomagokat tesz közzé. Az alábbi példák kifejezetten az 1.6 és a 2.0.1 verzióra vonatkoznak; 2.1-es telepítéshez a megfelelő specifikációt használja. Üzembe helyezéskor vagy frissítéskor ellenőrizze a hivatalos letöltéseket és hibajegyzékeket.

2. A tényleges töltőről rögzítse az azonosítót

Kezdjen néhány egyértelműen azonosítható tesztkártyával. A nyomtatott kártyahivatkozást tartsa külön az elektronikus értéktől: egy látható sorozatszám, például a CRF-TEST-0042, hasznos az ügyféltámogatáshoz, de dokumentálni kell a háttérrendszerbeli azonosítóhoz való kapcsolatát.

Online OCPP-jogosultság-ellenőrzési kéréshez az alábbi részletek szemléltető, fiktív azonosítót használó üzenettartalmak:

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

{"idToken":{"idToken":"04A1B2C3D4E5F7","type":"ISO14443"}}

Ezek a részletek nem tartalmazzák a WebSocket-üzenetkeretezést. A hivatalos sémák az 1.6-os idTag mezőhöz legfeljebb 20 karaktert, a 2.0.1-es idToken szöveghez 36 karaktert engednek meg; a 2.0.1 a tokentípust is megköveteli. Az integrációban használt OCPP 1.6 csomag vagy OCPP 2.0.1 Edition 4 csomag alapján végezze az ellenőrzést.

A helyben engedélyezett indítás más üzenetsorrendet követhet. Az integrátor azonosítsa, hogy ebben az üzemmódban hol rögzül az azonosítóeszköz és az engedélyezési döntés.

3. A kártyák importálása előtt egyeztessék az UID ábrázolását

ISO14443 token esetén az OCPP 2.0.1 hexadecimális UID-bájtokat javasol, a 0. bájttal kezdve. A régebbi termékek működését ettől függetlenül ellenőrizni kell: a Wallbox OCPP-aktiválási útmutatója az általa lefedett termékekhez elválasztó nélküli, little-endian hexadecimális értékeket ír elő. Ez termékspecifikus utasítás, nem általános konverziós szabály. Lásd az OCPP 2.0.1 C.1.1 jogosultság-ellenőrzési szakaszát és a Wallbox aktiválási útmutatójának 14. és 20. oldalát.

Ennek a fiktív, hétbájtos sorozatnak az ábrázolásai:

A táblázat átalakításokat mutat be, nem négy felcserélhető háttérrendszerbeli értéket. Az integráció által megkövetelt ábrázolást importálja. A bájtok megfordítása karakterpárok sorrendjét cseréli fel; az egyes karakterek megfordítása más eredményt ad.

Írásban rögzítse a szállítói adatok, az állomásnapló és a háttérrendszer importmezője közötti megfeleltetést. Szerepeljen benne a bájthossz, a hexadecimális vagy decimális jelölés, a bájtsorrend, az elválasztók és minden kifejezetten dokumentált átalakítás. Őrizze meg a nyers forrásfájlt. Kerülje a nem dokumentált csonkolást és a hiányzó bájtok találgatását.

Ellenőrizze az azonosítót átalakító eszközbeállításokat. A Wallbox eM4 WebAdmin kézikönyve például tartalmaz „Shorten UIDs” beállítást, és figyelmeztet arra, hogy az engedélyezési beállítások a helyi felületről és a háttérrendszerből is módosíthatók. Lásd a Wallbox WebAdmin kézikönyvének 23. oldalát. Mindkét rendszer csatlakozása után rögzítse a tényleges konfigurációt.

Az azonosítóoszlopokat szövegként importálja a táblázatkezelőbe. Az Excel eltávolíthatja a kezdő nullákat, numerikus pontossága pedig 15 értékes számjegyre korlátozott; a decimális példánk 16 számjegyű. Az adatok megváltozása után alkalmazott megjelenítési formátum nem állítja vissza az eredeti azonosítót. Kövesse a Microsoft útmutatását az azonosítóadatok megőrzéséről.

A ChargeRFID UID-konverterével megvizsgálhatja az ábrázolásokat, az azonosítófájl-egyeztető eszközzel pedig összehasonlíthatja a gyártási és háttérrendszerbeli fájlokat. Mielőtt az egész tételre alkalmazná, ellenőrizze a javasolt megfeleltetést egy tényleges töltőnapló alapján.

4. Regisztrálja az azonosítóeszközöket és rendelje hozzá az üzleti jogosultságokat

A platform dokumentált regisztrációs vagy importálási folyamatával hozza létre az azonosítóeszköz rekordját. Kapcsolja a kívánt járművezetőhöz, járműhöz, részleghez vagy ügyfélfiókhoz aszerint, hogyan rendeli hozzá a szervezet a töltéseket.

Minden pilotazonosítóeszközhöz rögzítse:

Ezeket külön átvételi kérdésként kezelje. Egy azonosítóeszköz szerepelhet az adatbázisban úgy is, hogy nincs meg a megfelelő helyszíni jogosultsága vagy fiókhozzárendelése. A sikeres indítás sem igazolja önmagában a helyes elszámolási feltételek alkalmazását.

Használjon regisztrációs nyilvántartást tételhivatkozással, importeredménnyel, kivételindoklással és ellenőrrel. Kiadás előtt rendezze a duplikált értékeket és az ütköző hozzárendeléseket. Igazítsa az UID-adatátadási sablont a platform tényleges importkövetelményeihez; a példasora tesztadat.

Közös használatú járműveknél egyeztessék, ki állíthatja le a töltést. Az OCA OCPP 1.6 tesztesetei kifejezetten vizsgálják az indító kártyával, illetve egyező szülőazonosítóval összekapcsolt másik kártyával történő leállítást. Tesztelje az engedélyezni kívánt csoportműködést. Lásd az OCTT 2026-02 tesztesetek 2.3.1 és 2.3.2 szakaszát.

5. Határozzon meg egyértelmű offline hozzáférési szabályzatot

Döntse el, folytatódhasson-e a töltés, ha az állomás nem éri el a kezelőrendszert. Egy korlátozott hozzáférésű flottatelepen észszerű kiindulási szabály, hogy kimaradáskor a helyben engedélyezett azonosítóeszközöket elfogadják, az ismeretlen kártyákat pedig elutasítják. Mielőtt erre támaszkodna, ellenőrizze, hogy a berendezés képes megvalósítani ezt a szabályzatot.

Az engedélyezési gyorsítótár korábbi adatcserékből származó engedélyezési információkat tárol. A helyi engedélyezési listát a háttérrendszer kezeli és szinkronizálja. Két külön mechanizmusról van szó. Az egyik törlése nem igazolja a másik frissülését. Az OCPP 1.6 a specifikáció 3.5 szakaszában ismerteti a kapcsolatukat.

Az alábbiak verziófüggő elnevezések, amelyeket az integrátorral kell megbeszélni; ez nem a töltőbe bemásolható konfigurációs fájl:

Az elnevezések nem jelentik, hogy minden funkció megvalósított, engedélyezett vagy írható. Az OCPP 2.0.1 komponens- és változócímzést használ; az eszközmodell és az adott használati eset határozza meg az egyes beállítások működését. Lásd az Edition 4 jogosultság-ellenőrzési és hivatkozott változókat tárgyaló szakaszait.

Rögzítse a helyi lista kapacitását, a frissítés visszaigazolását, a lejárat kezelését, az újraindítás utáni adatmegőrzést és a megtelt tároló melletti működést. Teszteljen olyan ismert azonosítóeszközt, amelyet még soha nem használtak az állomáson, és olyat is, amelyet ott már engedélyeztek. Ez segít megállapítani, melyik helyi mechanizmusra támaszkodik ténylegesen a telepítés.

A teszt terjedjen ki az újracsatlakozásra is. Ellenőrizze, hogyan jutnak el az offline tranzakciók a háttérrendszerbe, hogyan történik az egyeztetésük, és mi történik a folyamatban lévő töltéssel, ha a kapcsolat helyreállása után a háttérrendszer elutasítja az azonosítóeszközt. A helyszín tulajdonosával egyeztessék az elfogadható működési és pénzügyi kitettséget.

6. Tudatosan válassza meg az azonosítóeszköz biztonsági modelljét

Kérdezze meg, hogy az olvasó csupán egy azonosítót olvas ki, vagy kriptográfiai hitelesítést végez az azonosítóeszközzel. A kizárólag UID-t használó megoldásban az egyező azonosító elfogadása nem bizonyítja kriptográfiai titok birtoklását. A biztonsági funkciókkal rendelkező chip vásárlása csak akkor teremt értéket, ha a telepített olvasó és alkalmazás használja is ezeket.

Ha kriptográfiai kártyahitelesítés szükséges, dokumentálja a támogatott alkalmazást, a kulcsok tulajdonosát, a kezdeti konfigurálás folyamatát, a csereeljárást és a migrációs felelősségeket. Titkos adatokat ne tegyen UID-adatátadási fájlokba. A NIST RFID-biztonsági útmutatójának 5.3.1 szakasza ismerteti az azonosítók és a hitelesítési kontrollok közötti különbséget. Ez 2007-ben megjelent alapozó útmutató; a támogatott algoritmusok és kulcskezelési mechanizmusok kiválasztásához aktuális termékdokumentációt használjon.

Az állomás és a háttérrendszer kapcsolatát külön biztosítsa. Az OCA aktuális Security Operations Guide dokumentumának 4.2 és 4.4 szakasza a Security Profile 2 profilt TLS és Basic Authentication, a Profile 3 profilt TLS és kliensoldali tanúsítványok együtteseként írja le, és a hitelesítő adatok tárolásával is foglalkozik. Ellenőrizze az alkalmazott átviteli biztonsági profilt, a tanúsítvány-ellenőrzést és az állomás hitelesítő adatainak kezelését. Ezek a beállítások a kártya–olvasó kapcsolattól eltérő kapcsolatot védenek.

7. Csak a szolgáltatás igénye esetén adjon hozzá roamingengedélyezést

Egy zárt munkahelyi telepítéshez elegendő lehet a saját platform azonosítóeszköz-nyilvántartása. A roaming újabb rendszerhatárt hoz létre: a töltőpont-üzemeltetőnek, azaz a CPO-nak a támogatott integráción és üzleti megállapodáson keresztül engedélyt kell kapnia az érintett elektromobilitási szolgáltatótól, azaz az eMSP-től.

Az OCPI 2.3.0 tokenrekordja tartalmazza a tulajdonos szolgáltató ország- és szereplőazonosítóját, a token UID-jét, típusát, érvényességét és engedélyezési listára vonatkozó szabályát. Az ALLOWED_OFFLINE szabály a CPO és az eMSP közötti kommunikációra vonatkozik. A töltő és a CSMS közötti kapcsolat megszakadása ettől különálló üzemzavar. Ha mindkét határ jelen van, tesztelje mindkettőt.

A Tokens modul különbséget tesz az érvényes token és az adott helyszínen engedélyezett token között is. Az érvénytelenítés egy frissített, valid: false értékű tokennel terjed tovább; ezen az interfészen nem a tokenek törlése szolgál erre. Vesse össze a hivatalos OCPI 2.3.0 Tokens modult a partnerével egyeztetett verzióval.

A pilothoz nevezze meg a kibocsátót és a részt vevő hálózatot, határozza meg az elvárt engedélyezési útvonalat, és ellenőrizze a létrejövő töltési folyamatot és töltési rekordot. Ugyanazon fizikai kártya több szolgáltatásban való használatához is szükséges a megfelelő regisztráció, jogosultság és megállapodás.

8. Az üzembe helyezéskor ellenőrizze a teljes hozzáférési életciklust

Használjon tesztmátrixot, amelyben az elvárt eredményeket a teszt előtt rögzítik. Futtassa le minden eltérő hardver-, firmware- és háttérrendszer-konfiguráción, majd szúrópróbaszerűen ellenőrizze a telepített állományt a jóváhagyott konfigurációhoz képest.

Minden futtatásnál őrizze meg az időpontot, az állomás- és csatlakozóazonosítókat, a firmware-t, a tesztkártya hivatkozását, a tényleges konfigurációt, az elvárt és tényleges eredményt, valamint a kapcsolódó tranzakciós rekordot. Az üzemeltető csapaton kívül megosztott bizonyítékokban fedje el a személyes adatokat.

Kártyavesztéskor rögzítse a bejelentés időpontját, és azt, mikor igazolta vissza a változást minden csatlakozó rendszer. Egy leválasztott állomás nem tudja azonnal fogadni az új visszavonást. A tényleges kitettség a tárolt engedélyezési állapottól, a lejárati szabályoktól és az újracsatlakozás működésétől függ. Az üzemeltetési eljárás térjen ki erre az időszakra.

A sikertelen kártyaolvasást a megfelelő rendszerhatáron vizsgálja

Gyűjtse össze egy sikertelen próbálkozás időbélyegét és kártyahivatkozását, majd haladjon végig a bizonyítékokon. Ezek az ellenőrzések szűkítik a vizsgálatot anélkül, hogy minden elutasításnál azonos okot feltételeznének.

Példa a rendszer bevezetésére egy flottatelepen

Vegyünk egy fiktív telepet 60 járművezetővel, 12 töltőponttal és két töltőmodellel. Az üzemeltető a hozzáférést egyéni járművezetőkhöz kívánja rendelni, a telepre korlátozva, és azt szeretné, hogy a jóváhagyott vezetők a háttérrendszer kimaradása alatt is tölthessenek.

Kezdjen öt mintaazonosítóeszközzel. Minden töltőmodellen rögzítse a jelentett azonosítót, és egyeztessék a szállítói fájlhoz való megfeleltetést. Regisztrálja a mintákat pilotfiókba, adjon telepi hozzáférést, és ellenőrizze a kívánt költséghelyet.

Ha a berendezés támogat kezelt helyi listát, töltse fel előre a pilotazonosítókat, és rögzítse a visszaigazolt verziót. Ennél a javasolt szabályzatnál az ismeretlen offline azonosítók engedélyezése maradjon kikapcsolva. Ellenőrzött teszt során válassza le az állomást a CSMS-ről, majd próbáljon ki egy előre feltöltött kártyát, egy ismeretlen kártyát és egy visszavont kártyát, amelynek elavult helyi állapotát tudatosan dokumentálták. Állítsa helyre a kapcsolatot, és ellenőrizze a frissítést és a tranzakciós rekordokat.

Mindkét modellen végezze el az online elutasítási, töltésleállítási és elszámolási teszteket. A pilot sikerét követően egyeztesse a 60 kártyás gyártási fájlt a háttérrendszer nyilvántartásával, rendezze a kivételeket, és ossza ki a kártyákat egyszerű kártyavesztési bejelentési eljárással. A firmware, az olvasó üzemmódja vagy a platform lényeges változásai után ismételje meg az érintett átvételi teszteket.

Megrendelés előtt tisztázandó kérdések

Szükséges az RFID-töltőkártyák programozása?

A kártya meglévő UID-jét kiolvasó megoldásnál a beállítás állhat az érték regisztrálásából és a platformbeli hozzáférés hozzárendeléséből. Védett alkalmazást használó megoldáshoz kártyaperszonalizálás és összehangolt olvasókonfiguráció is szükséges lehet. Bármely szolgáltatás megrendelése előtt pontosítsa az olvasó teljes munkafolyamatát.

Egy meglévő dolgozói belépőkártya a töltőt is feloldhatja?

Ez lehetséges lehet, ha az olvasó támogatja a belépőkártya technológiáját, a szükséges azonosító elérhető és stabil, a platform pedig engedi a regisztrálását. Kérje a beléptetőrendszer tulajdonosának jóváhagyását, és teszteljen tényleges mintákat. Platformspecifikus regisztrációs példaként az Easee fiók- és helyikulcs-dokumentációja különböző regisztrációs hatóköröket ismertet, és felhívja a figyelmet a változó azonosítókra.

Egy kártya minden töltőhálózatban működik?

A kívánt hálózatokat egyenként vizsgálja meg. A fizikai olvashatóság, az azonosító regisztrációja, a fiókjogosultságok és az esetleges roamingmegállapodás egyaránt az átvételi feltételek részei. A részt vevő hálózatot tesztelje, ne a kártya külsejéből következtessen a lefedettségre.

Mit kapjon meg a kártyaszállító?

Adja át az olvasókövetelményeket, a jóváhagyott mintaazonosító-megfeleltetést, a látható számozási rendszert, az anyag- és nyomdai specifikációt, a mennyiséget és az egyeztetett adatátadási formátumot. Nevezze meg a háttérrendszerbe importálás és a mintaátvétel felelősét. Ha a megoldás megköveteli, az alkalmazástitkokat külön egyeztetett, biztonságos konfigurálási eljárással adja át.

Készítsen mintaspecifikációt a telepítéséhez

Egy specifikációban foglalja össze a töltőmodellt és firmware-t, a háttérrendszer nevét és protokollverzióját, a szükséges azonosítóeszköz-üzemmódot, az igazolt azonosítóábrázolást és a tervezett offline szabályzatot. A ChargeRFID azonosítóadat-laborjával áttekintheti az adatátadást, és kész mintákat kérhet a pilothoz. A gyártási megrendelés kiadása előtt együtt hagyja jóvá a fizikai azonosítóeszközt és a teljes hozzáférési folyamatát.