Jak nastavit přístup RFID k firemním nabíječkám elektromobilů

Chcete-li nastavit přístup RFID k firemním nabíječkám elektromobilů, ověřte, že čtečka podporuje zvolený identifikační prostředek, zachyťte identifikátor, který nabíječka skutečně hlásí, zaregistrujte tuto hodnotu v nabíjecí platformě, přidělte potřebná přístupová oprávnění a otestujte celou nabíjecí relaci. Poté ověřte, co se stane při výpadku připojení a při odebrání oprávnění kartě.

Výrobní sérii objednejte až poté, co reprezentativní vzorek úspěšně projde tímto postupem. Úspěšné přiložení karty potvrzuje pouze část výsledku. Přejímací záznam by měl doložit také správný nabíjecí bod, účet, záznam energie a chování při zastavení.

Tento průvodce se zabývá správou přístupu po instalaci a uvedení nabíjecího zařízení do provozu kvalifikovaným instalačním technikem. Je určen týmu, který propojuje fyzické identifikační prostředky se systémem správy nabíjení.

Ujasněte si, který systém rozhoduje o čem

Při online autorizaci čtečka RFID získá identifikátor, nabíjecí stanice jej předá systému správy nabíjecích stanic neboli CSMS a platforma vrátí výsledek autorizace. OCPP řídí komunikaci mezi stanicí a tímto systémem správy. Rádiové rozhraní mezi kartou a čtečkou je samostatnou částí integrace. Viz přehled protokolu od Open Charge Alliance.

Za každou vrstvu určete jednu odpovědnou osobu. Dodavatel karet může poskytnout dohodnutý fyzický prostředek a soubor identifikátorů; integrátor nabíječek potvrzuje chování čtečky; provozovatel platformy řídí registraci účtů a oprávnění. Před zahájením uvádění do provozu zaznamenejte, kdo řeší nesrovnalosti.

1. Potvrďte možnosti čtečky a autorizace

Vyžádejte si specifikaci čtečky pro přesný model nabíječky, hardwarovou revizi a nainstalovaný firmware. Zaznamenejte podporované bezkontaktní standardy, používaný režim identifikačního prostředku a případné nastavitelné převody identifikátoru. Označení typu „s podporou RFID“ na tyto otázky neodpovídá.

NFC pracuje na frekvenci 13,56 MHz a zahrnuje několik bezkontaktních technologií včetně ISO/IEC 14443 Type A, Type B a ISO/IEC 15693. Samotná shoda frekvence proto není úplnou nákupní specifikací. Ověřte soulad skutečné technologie karty s implementací čtečky. Technický přehled NFC Forum vysvětluje tyto základní protokoly.

Dále zjistěte, co stanice a backend skutečně implementují:

Certifikaci OCPP je třeba posuzovat na úrovni jednotlivých funkcí. Aktualizace OCA z prosince 2025 řadí Local List Management mezi volitelné funkce profilu OCPP 2.0.1 Core. Aktualizovaný certifikační program proto nezaručuje podporu místních seznamů u každé certifikované stanice. Také aplikační poznámka OCPP 2.Lite, oddíl C, vydaná OCA, vysvětluje, že mezipaměť autorizace může být vynechána a implementace mohou podporovat různé autorizační metody.

Vyžádejte si rozsah certifikátu a Protocol Implementation Conformance Statement, jsou-li k dispozici, a porovnejte je s nainstalovaným softwarem. Tyto podklady uchovávejte s konfigurací lokality.

OCA aktuálně vydává balíčky OCPP 1.6, 2.0.1 a 2.1. Následující příklady se týkají konkrétně verzí 1.6 a 2.0.1; pro instalaci 2.1 použijte odpovídající specifikaci. Při uvádění do provozu nebo aktualizaci zkontrolujte oficiální soubory ke stažení a opravy.

2. Zachyťte identifikátor ze skutečné nabíječky

Začněte malou sadou rozlišitelných testovacích karet. Tištěné označení karty oddělte od elektronické hodnoty: viditelné sériové číslo, například CRF-TEST-0042, pomáhá podpoře, ale jeho vztah k identifikátoru v backendu musí být zdokumentován.

Následující ukázkové fragmenty dat online autorizačního požadavku OCPP používají fiktivní identifikátor:

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

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

Tyto fragmenty vynechávají rámování zpráv WebSocket. Oficiální schémata stanovují nejvýše 20 znaků pro idTag ve verzi 1.6 a 36 pro řetězec idToken ve verzi 2.0.1; verze 2.0.1 vyžaduje také typ tokenu. Proveďte validaci proti balíčku OCPP 1.6 nebo balíčku OCPP 2.0.1 Edition 4 používanému pro Vaši integraci.

Místně autorizované spuštění může mít jinou posloupnost zpráv. Požádejte integrátora, aby určil, kde se v tomto režimu zaznamenává identifikační prostředek a autorizační rozhodnutí.

3. Dohodněte reprezentaci UID před importem karet

Pro token ISO14443 doporučuje OCPP 2.0.1 hexadecimální bajty UID s bajtem 0 na prvním místě. Přesto je nutné ověřit chování starších produktů: návod k aktivaci OCPP od Wallbox stanovuje pro produkty, na které se vztahuje, hexadecimální hodnoty little-endian bez oddělovačů. Jde o pokyn pro konkrétní produkty, nikoli o univerzální převodní pravidlo. Viz OCPP 2.0.1, autorizační oddíl C.1.1 a návod k aktivaci Wallbox, strany 14 a 20.

Pro tuto fiktivní sekvenci sedmi bajtů jsou reprezentace následující:

Tabulka ukazuje převody, nikoli čtyři zaměnitelné hodnoty pro backend. Importujte reprezentaci požadovanou integrací. Obrácení bajtů mění jejich pořadí po dvojicích znaků; obrácení jednotlivých znaků dává jiný výsledek.

Uchovávejte písemné mapování mezi daty dodavatele, provozním záznamem stanice a importním polem backendu. Zahrňte délku v bajtech, hexadecimální nebo desítkový zápis, pořadí bajtů, oddělovače a veškeré výslovně zdokumentované převody. Zachovejte nezpracovaný zdrojový soubor. Vyhněte se nezdokumentovanému zkracování a nehádejte chybějící bajty.

Prověřte nastavení zařízení, která převádějí identifikátory. Příručka Wallbox eM4 WebAdmin například obsahuje volbu „Shorten UIDs“ a upozorňuje, že autorizační nastavení lze měnit z místního rozhraní i z backendu. Viz příručka Wallbox WebAdmin, strana 23. Zaznamenejte účinnou konfiguraci po připojení obou systémů.

Sloupce identifikátorů importujte do tabulkových procesorů jako text. Excel může odstranit úvodní nuly a omezuje číselnou přesnost na 15 platných číslic; náš desítkový příklad má 16 číslic. Dodatečné nastavení formátu zobrazení po změně dat původní identifikátor neobnoví. Řiďte se pokyny Microsoftu pro zachování dat identifikátorů.

K prohlédnutí reprezentací použijte převodník UID ChargeRFID a k porovnání výrobních souborů se soubory backendu nástroj pro porovnání souborů identifikačních prostředků. Před použitím na celou sérii potvrďte navržené mapování podle skutečného diagnostického záznamu nabíječky.

4. Zaregistrujte identifikační prostředky a přiřaďte obchodní oprávnění

Vytvořte záznam identifikačního prostředku podle zdokumentovaného registračního nebo importního postupu platformy. Propojte jej se zamýšleným řidičem, vozidlem, oddělením nebo zákaznickým účtem podle toho, jak Vaše organizace přiřazuje nabíjení.

U každého pilotního identifikačního prostředku zaznamenejte:

Posuzujte je jako samostatná přejímací kritéria. Identifikační prostředek může být v databázi, a přesto nemít zamýšlené oprávnění k lokalitě nebo přiřazení k účtu. Ani úspěšné spuštění neprokazuje, že se použilo správné fakturační ujednání.

Používejte registrační evidenci s označením série, výsledkem importu, důvodem výjimky a kontrolující osobou. Před vydáním vyřešte duplicitní hodnoty a konfliktní přiřazení. Přizpůsobte šablonu pro předání UID skutečné importní specifikaci platformy; ukázkový řádek obsahuje testovací data.

U sdílených vozidel dohodněte, kdo smí relaci zastavit. Testovací případy OCPP 1.6 od OCA výslovně zahrnují zastavení zahajovací kartou i jinou kartou propojenou shodným nadřazeným identifikátorem. Otestujte skupinové chování, které chcete povolit. Viz testovací případy OCTT 2026-02, oddíly 2.3.1 a 2.3.2.

5. Stanovte výslovnou politiku přístupu offline

Rozhodněte, zda má být nabíjení dostupné, když stanice nedosáhne na svůj systém správy. Pro uzavřené depo vozového parku je rozumným výchozím pravidlem přijímat během výpadku zamýšlené místně autorizované prostředky a odmítat neznámé karty. Než se na tuto politiku spolehnete, ověřte, že ji zařízení dokáže realizovat.

Mezipaměť autorizace uchovává autorizační informace získané při předchozích výměnách. Místní autorizační seznam je spravován a synchronizován z backendu. Jde o odlišné mechanismy. Vymazání jednoho neprokazuje aktualizaci druhého. OCPP 1.6 jejich vztah popisuje v oddílu 3.5 specifikace.

Následující názvy jsou příklady specifické pro danou verzi určené k diskusi s integrátorem, nikoli konfigurační soubor k vložení do nabíječky:

Názvy neznamenají, že každá funkce je implementována, povolena nebo zapisovatelná. OCPP 2.0.1 používá adresování komponent a proměnných; model zařízení a příslušný případ užití určují fungování každého nastavení. Viz oddíly Edition 4 o autorizaci a odkazovaných proměnných.

Zaznamenejte kapacitu místního seznamu, potvrzení aktualizace, zpracování vypršení platnosti, zachování po restartu a chování při plném úložišti. Otestujte známý prostředek, který na stanici ještě nikdy použit nebyl, i prostředek, který na ní již autorizován byl. Pomůže to zjistit, na kterém místním mechanismu nasazení skutečně závisí.

Do testu zahrňte obnovení připojení. Ověřte, jak offline transakce dorazí do backendu, jak se párují a co se stane s probíhající relací, pokud backend po obnovení spojení odmítne její identifikační prostředek. S vlastníkem areálu dohodněte přijatelnou míru provozního a finančního rizika.

6. Zvolte bezpečnostní model identifikačních prostředků uvážlivě

Zjistěte, zda čtečka pouze čte identifikátor, nebo provádí s prostředkem kryptografickou autentizaci. U návrhu založeného pouze na UID přijetí shodného identifikátoru neprokazuje držení kryptografického tajemství. Nákup čipu s bezpečnostními funkcemi přináší hodnotu jen tehdy, když je nasazená čtečka a aplikace využívají.

Je-li vyžadována kryptografická autentizace karty, zdokumentujte podporovanou aplikaci, vlastnictví klíčů, postup přípravy a nastavení, postup výměny a odpovědnost za migraci. Tajné údaje nepatří do souborů pro předání UID. Bezpečnostní doporučení NIST pro RFID, oddíl 5.3.1, popisuje rozdíl mezi identifikátory a autentizačními kontrolami. Jde o základní doporučení vydané v roce 2007; pro výběr podporovaných algoritmů a mechanismů správy klíčů použijte aktuální dokumentaci produktů.

Samostatně zabezpečte připojení mezi stanicí a backendem. Aktuální Security Operations Guide od OCA, oddíly 4.2 a 4.4, popisuje Security Profile 2 jako TLS s Basic Authentication a Profile 3 jako TLS s klientskými certifikáty a zabývá se ukládáním autentizačních údajů. Potvrďte nasazený transportní profil, ověřování certifikátů a správu autentizačních údajů stanice. Tato nastavení chrání jiné připojení než spojení mezi kartou a čtečkou.

7. Roamingovou autorizaci přidejte jen tehdy, když ji služba vyžaduje

Soukromé nabíjení v zaměstnání může potřebovat pouze registr identifikačních prostředků vlastní platformy. Roaming přidává další rozhraní: provozovatel nabíjecích bodů neboli CPO musí získat autorizaci od příslušného poskytovatele služeb elektromobility neboli eMSP prostřednictvím podporované integrace a obchodního ujednání.

V OCPI 2.3.0 obsahuje záznam tokenu identifikátory země a subjektu poskytovatele, který jej vlastní, UID tokenu, typ, platnost a politiku seznamu povolených tokenů. Politika ALLOWED_OFFLINE se týká komunikace mezi CPO a eMSP. Ztráta připojení nabíječky k CSMS je samostatný výpadek. Pokud existují obě rozhraní, otestujte je obě.

Modul Tokens také rozlišuje mezi platným tokenem a tokenem povoleným na konkrétním místě. Zneplatnění se šíří prostřednictvím aktualizovaného tokenu s valid: false; mazání tokenů tímto rozhraním není zamýšleným mechanismem. Porovnejte oficiální modul Tokens OCPI 2.3.0 s verzí dohodnutou s partnerem.

Pro pilot pojmenujte vydavatele a zapojenou síť, stanovte očekávanou autorizační cestu a zkontrolujte výslednou relaci a záznam nabíjení. Opětovné využití stejné fyzické karty u více služeb stále vyžaduje příslušné registrace, oprávnění a dohody.

8. Při uvádění do provozu otestujte celý životní cyklus přístupu

Použijte testovací matici s očekávanými výsledky zapsanými před testem. Proveďte ji pro každou odlišnou konfiguraci hardwaru, firmwaru a backendu a následně namátkově ověřte soulad instalovaných zařízení se schválenou konfigurací.

U každého běhu uchovejte čas, identifikátory stanice a konektoru, firmware, označení testovací karty, účinnou konfiguraci, očekávaný výsledek, skutečný výsledek a relevantní transakční záznam. V důkazech sdílených mimo provozní tým zakryjte osobní údaje.

Při ztrátě karty zaznamenejte čas přijetí hlášení a čas, kdy každý připojený systém změnu potvrdil. Odpojená stanice nemůže nové odebrání oprávnění přijmout okamžitě. Praktické riziko závisí na uloženém autorizačním stavu, pravidlech vypršení platnosti a chování při obnovení spojení. Tento interval řešte v provozním postupu.

Neúspěšné přiložení diagnostikujte na správném rozhraní

Shromážděte jednu neúspěšnou zkoušku s časovým razítkem a označením karty a poté projděte dostupné důkazy. Tyto kontroly zúží vyšetřování, aniž by předpokládaly stejnou příčinu každého odmítnutí.

Příklad nasazení v depu vozového parku

Uvažujme fiktivní depo se 60 řidiči, 12 nabíjecími body a dvěma modely nabíječek. Provozovatel chce přiřazovat přístup jednotlivým řidičům, omezit jej na depo a schváleným řidičům umožnit nabíjení při výpadku backendu.

Začněte pěti vzorky identifikačních prostředků. U každého modelu nabíječky zachyťte hlášený identifikátor a dohodněte mapování na soubor dodavatele. Zaregistrujte vzorky v pilotním účtu, přiřaďte přístup do depa a potvrďte zamýšlené nákladové středisko.

Pokud zařízení podporuje spravovaný místní seznam, předem nahrajte pilotní prostředky a zaznamenejte potvrzenou verzi. Pro tuto navrženou politiku ponechte neznámé offline prostředky zakázané. V řízeném testu odpojte stanici od CSMS a poté vyzkoušejte předem nahranou kartu, neznámou kartu a kartu s odebraným oprávněním se záměrně zdokumentovaným zastaralým místním stavem. Obnovte připojení a ověřte aktualizaci i transakční záznamy.

Na obou modelech dokončete testy online odmítnutí, zastavení relace a vyúčtování. Jakmile pilot uspěje, porovnejte výrobní soubor 60 karet s registrem backendu, vyřešte výjimky a vydejte karty spolu s jednoduchým postupem hlášení ztráty. Po významných změnách firmwaru, režimu čtečky nebo platformy zopakujte příslušné přejímací testy.

Otázky k vyřešení před objednávkou

Je nutné RFID karty pro nabíjení programovat?

U návrhu, který čte stávající UID karty, může nastavení spočívat v registraci této hodnoty a přidělení přístupu v platformě. Návrh využívající chráněnou aplikaci může vyžadovat personalizaci karty a koordinovanou konfiguraci čtečky. Před objednáním kterékoli služby specifikujte přesný pracovní postup čtečky.

Může stávající zaměstnanecká karta odemknout také nabíječku?

Může to být možné, pokud čtečka podporuje technologii karty, požadovaný identifikátor je dostupný a stabilní a platforma umožňuje registraci. Získejte souhlas vlastníka kartového systému a otestujte skutečné vzorky. Jako příklad registrace specifické pro platformu popisuje dokumentace Easee k účtům a místním klíčům odlišné rozsahy registrace a upozorňuje na měnící se identifikátory.

Bude jedna karta fungovat ve všech nabíjecích sítích?

Zamýšlené sítě prověřte jednotlivě. Fyzická čitelnost, registrace prostředku, oprávnění účtu a případná roamingová dohoda jsou součástí přejímacích kritérií. Otestujte zapojenou síť, místo abyste odvozovali pokrytí ze vzhledu karty.

Co má obdržet dodavatel karet?

Poskytněte požadavky na čtečku, schválené mapování identifikátoru vzorku, schéma viditelného číslování, specifikaci materiálu a tisku, množství a dohodnutý formát předání dat. Uveďte osobu odpovědnou za import do backendu a přejímku vzorků. Pokud to návrh vyžaduje, předávejte tajné údaje aplikace samostatně dohodnutým bezpečným postupem přípravy a nastavení.

Připravte specifikaci vzorků pro své nasazení

Do jedné specifikace spojte model nabíječky a firmware, název backendu a verzi protokolu, požadovaný režim prostředku, potvrzenou reprezentaci identifikátoru a zamýšlenou offline politiku. K posouzení předání dat využijte laboratoř identifikačních prostředků ChargeRFID a pro pilot si vyžádejte hotové vzorky. Před uvolněním výrobní objednávky schvalte fyzický prostředek společně s celým jeho přístupovým postupem.