De ChargeRFID
Metoda de verificare: Am verificat acest ghid în raport cu referințele primare de reglementare, de protocol și ale producătorilor enumerate mai jos. Recomandările de produs reflectă perspectiva ChargeRFID în calitate de producător și ar trebui validate cu cititorul RFID, stația de încărcare și sistemul central pe care le utilizați.

Pentru a configura accesul RFID la stațiile de încărcare pentru uz comercial, confirmați că cititorul acceptă mijlocul de identificare ales, preluați identificatorul raportat efectiv de stație, înregistrați valoarea în platforma de gestionare a încărcării, atribuiți drepturile necesare și testați întreaga sesiune de încărcare. Apoi verificați ce se întâmplă când conexiunea se întrerupe și când un card este revocat.
Comandați lotul de producție după ce un eșantion reprezentativ trece prin acest proces cu succes. O citire reușită confirmă doar o parte din rezultat. Procesul-verbal de recepție trebuie să confirme și punctul de încărcare, contul, înregistrarea energiei și comportamentul la oprire.
Acest ghid tratează gestionarea accesului după instalarea și punerea în funcțiune a echipamentelor de către un instalator calificat. Se adresează echipei care conectează mijloacele fizice de identificare la sistemul de gestionare a încărcării.
Stabiliți ce sistem ia fiecare decizie
Într-un flux de autorizare online, cititorul RFID obține un identificator, stația îl transmite unui sistem de gestionare a stațiilor de încărcare, sau CSMS, iar platforma returnează rezultatul autorizării. OCPP reglementează comunicarea dintre stație și sistemul de gestionare. Interfața radio dintre card și cititor reprezintă o parte separată a integrării. Consultați prezentarea protocoalelor Open Charge Alliance.
| Nivel | Ce trebuie stabilit |
|---|---|
| Mijloc fizic de identificare și cititor | Cititorul poate obține identificatorul dorit sau poate autentifica aplicația de card dorită. |
| Stație și CSMS | Identificatorul raportat ajunge la sistemul central corect prin protocolul și în reprezentarea convenite. |
| Cont și politică de acces | Mijlocul de identificare este atribuit contului corect și locațiilor de încărcare permise. |
| Tranzacție și facturare | Sesiunea rezultată este atribuită și tarifată conform acordului comercial prevăzut. |
| Conexiune de roaming opțională | Operatorul punctelor de încărcare și furnizorul de servicii de mobilitate pot transmite și autoriza tokenul în baza acordului lor. |
Desemnați câte un responsabil pentru fiecare nivel. Furnizorul de carduri poate livra mijlocul fizic de identificare și fișierul de identificatori convenite; integratorul stației confirmă comportamentul cititorului; operatorul platformei controlează înregistrarea conturilor și permisiunile. Înainte de începerea punerii în funcțiune, consemnați cine rezolvă eventualele neconcordanțe.
1. Confirmați capabilitățile cititorului și ale autorizării
Solicitați specificația cititorului pentru modelul exact de stație, revizia hardware și firmware-ul instalat. Notați standardele contactless acceptate, modul de utilizare a mijloacelor de identificare și eventualele conversii configurabile ale identificatorului. O descriere precum „compatibil RFID” lasă aceste întrebări fără răspuns.
NFC funcționează la 13,56 MHz și include mai multe tehnologii contactless, între care ISO/IEC 14443 Type A, Type B și ISO/IEC 15693. Prin urmare, simpla potrivire a frecvenței nu reprezintă o specificație completă de achiziție. Corelați tehnologia efectivă a cardului cu implementarea cititorului. Prezentarea tehnică NFC Forum explică protocoalele de bază.
Stabiliți apoi ce implementează efectiv stația și sistemul central:
Certificarea OCPP trebuie analizată la nivel de funcționalitate. Actualizarea OCA din decembrie 2025 include Local List Management printre funcțiile opționale ale profilului OCPP 2.0.1 Core. Așadar, programul de certificare actualizat nu garantează că orice stație certificată acceptă liste locale. Nota de aplicație OCPP 2.Lite a OCA, secțiunea C, explică și că memoria cache de autorizare poate lipsi și că implementările pot accepta metode de autorizare diferite.
Solicitați domeniul de acoperire al certificatului și documentul Protocol Implementation Conformance Statement, dacă este disponibil, și comparați-le cu software-ul instalat. Păstrați aceste dovezi împreună cu configurația locației.
OCA publică în prezent pachete OCPP 1.6, 2.0.1 și 2.1. Exemplele de mai jos se referă în mod specific la 1.6 și 2.0.1; pentru o instalație 2.1, utilizați specificația corespunzătoare. Verificați descărcările și eratele oficiale la punerea în funcțiune sau la actualizare.
2. Preluați identificatorul de la stația efectivă

Începeți cu un set mic de carduri de test identificabile. Păstrați separat referința tipărită pe card și valoarea electronică: un număr de serie vizibil precum CRF-TEST-0042 este util pentru asistență, dar legătura sa cu identificatorul din sistemul central trebuie documentată.
Pentru o cerere de autorizare OCPP online, acestea sunt fragmente ilustrative de date, cu un identificator fictiv:
OCPP 1.6
{"idTag":"04A1B2C3D4E5F7"}OCPP 2.0.1
{"idToken":{"idToken":"04A1B2C3D4E5F7","type":"ISO14443"}}Aceste fragmente omit încadrarea mesajelor WebSocket. Schemele oficiale definesc maximum 20 de caractere pentru idTag în 1.6 și 36 pentru șirul idToken în 2.0.1; versiunea 2.0.1 impune și tipul tokenului. Validați conform pachetului OCPP 1.6 sau pachetului OCPP 2.0.1 Edition 4 utilizat în integrare.
O pornire autorizată local poate urma o altă secvență de mesaje. Cereți integratorului să identifice unde sunt înregistrate mijlocul de identificare și decizia de autorizare în acel mod.
3. Conveniți reprezentarea UID înainte de importul cardurilor
Pentru un token ISO14443, OCPP 2.0.1 recomandă octeții UID în format hexazecimal, cu octetul 0 primul. Comportamentul produselor mai vechi trebuie totuși verificat: ghidul de activare OCPP Wallbox specifică valori hexazecimale little-endian fără separatori pentru produsele pe care le acoperă. Aceasta este o instrucțiune specifică produsului, nu o regulă universală de conversie. Consultați OCPP 2.0.1, secțiunea de autorizare C.1.1 și ghidul de activare Wallbox, paginile 14 și 20.
Pentru această secvență fictivă de șapte octeți, reprezentările sunt:
| Reprezentare | Valoare |
|---|---|
| Octeți în ordinea indicată | 04 A1 B2 C3 D4 E5 F7 |
| Hexazecimal fără separatori | 04A1B2C3D4E5F7 |
| Ordinea octeților inversată | F7E5D4C3B2A104 |
| Zecimal fără semn, interpretând ordinea indicată cu octetul cel mai semnificativ primul | 1303689068602871 |
Tabelul prezintă transformări, nu patru valori interschimbabile în sistemul central. Importați reprezentarea cerută de integrare. Inversarea octeților schimbă ordinea perechilor de caractere; inversarea caracterelor individuale produce alt rezultat.
Documentați corespondența dintre datele furnizorului, jurnalul stației și câmpul de import al sistemului central. Includeți lungimea în octeți, notația hexazecimală sau zecimală, ordinea octeților, separatorii și orice transformare documentată explicit. Păstrați fișierul-sursă brut. Evitați trunchierea nedocumentată și presupunerile privind octeții lipsă.
Verificați setările dispozitivelor care transformă identificatorii. Manualul Wallbox eM4 WebAdmin include, de exemplu, opțiunea „Shorten UIDs” și avertizează că setările de autorizare pot fi modificate atât din interfața locală, cât și din sistemul central. Consultați manualul Wallbox WebAdmin, pagina 23. Consemnați configurația efectivă după conectarea ambelor sisteme.
Importați coloanele cu identificatori în foile de calcul ca text. Excel poate elimina zerourile inițiale și limitează precizia numerică la 15 cifre semnificative; exemplul nostru zecimal are 16 cifre. Aplicarea unui format de afișare după modificarea datelor nu recuperează identificatorul original. Urmați recomandările Microsoft pentru păstrarea datelor de identificare.
Utilizați convertorul UID ChargeRFID pentru a examina reprezentările și instrumentul de reconciliere a fișierelor de identificatori pentru a compara fișierele de producție cu cele din sistemul central. Confirmați corespondența propusă cu un jurnal real al stației înainte de a o aplica întregului lot.
4. Înregistrați mijloacele de identificare și atribuiți permisiunile comerciale

Creați înregistrarea mijlocului de identificare prin procedura documentată de înrolare sau import a platformei. Asociați-o șoferului, vehiculului, departamentului sau contului de client prevăzut, în funcție de modul în care organizația atribuie sesiunile de încărcare.
Pentru fiecare mijloc de identificare din proiectul-pilot, notați:
Tratați-le ca aspecte distincte ale recepției. Un mijloc de identificare poate apărea în baza de date fără să aibă permisiunea de locație sau atribuirea de cont dorită. La fel, o pornire reușită nu confirmă aplicarea condițiilor corecte de facturare.
Folosiți un registru de înrolare cu referința lotului, rezultatul importului, motivul excepțiilor și persoana care verifică. Rezolvați valorile duplicate și atribuirile contradictorii înainte de distribuire. Adaptați șablonul de predare a datelor UID la cerințele reale de import ale platformei; rândul exemplificativ conține date de test.
Pentru vehiculele utilizate în comun, conveniți cine poate opri o sesiune. Cazurile de test OCPP 1.6 ale OCA acoperă explicit oprirea cu cardul inițiator și oprirea cu alt card asociat printr-un identificator-părinte comun. Testați comportamentul de grup pe care doriți să îl activați. Consultați cazurile de test OCTT 2026-02, secțiunile 2.3.1 și 2.3.2.
5. Stabiliți o politică explicită de acces offline
Decideți dacă încărcarea trebuie să continue când stația nu poate contacta sistemul de gestionare. Pentru o bază de flotă cu acces restricționat, un punct de plecare rezonabil este acceptarea mijloacelor de identificare autorizate local și respingerea cardurilor necunoscute în timpul unei întreruperi. Confirmați că echipamentele pot aplica această politică înainte de a vă baza pe ea.
Memoria cache de autorizare păstrează informații de autorizare obținute din schimburi anterioare. Lista locală de autorizare este gestionată și sincronizată din sistemul central. Sunt mecanisme distincte. Golirea unuia nu confirmă actualizarea celuilalt. OCPP 1.6 descrie relația dintre ele în secțiunea 3.5 a specificației.
Acestea sunt exemple de denumiri specifice versiunilor, de discutat cu integratorul, nu un fișier de configurare de copiat în stație:
| Scop | OCPP 1.6 | OCPP 2.0.1 |
|---|---|---|
| Memorie cache de autorizare | AuthorizationCacheEnabled | AuthCacheEnabled |
| Listă locală de autorizare | LocalAuthListEnabled | LocalAuthListEnabled |
| Autorizare locală offline | LocalAuthorizeOffline | LocalAuthorizeOffline |
| Preautorizare locală | LocalPreAuthorize | LocalPreAuthorize |
| Mijloace de identificare necunoscute offline | AllowOfflineTxForUnknownId | OfflineTxForUnknownIdEnabled |
Denumirile nu confirmă că fiecare funcție este implementată, activată sau poate fi modificată. OCPP 2.0.1 utilizează adresarea prin componente și variabile; modelul dispozitivului și cazul de utilizare aplicabil determină modul de funcționare al fiecărei setări. Consultați secțiunile Edition 4 privind autorizarea și variabilele la care se face referire.
Consemnați capacitatea listei locale, confirmarea actualizării, tratarea expirării, păstrarea datelor după repornire și comportamentul când memoria este plină. Testați un mijloc de identificare cunoscut, care nu a mai fost folosit pe stație, precum și unul autorizat anterior acolo. Astfel puteți stabili pe ce mecanism local se bazează efectiv implementarea.
Includeți și reconectarea în test. Verificați cum ajung tranzacțiile offline în sistemul central, cum sunt reconciliate și ce se întâmplă cu o sesiune în curs dacă sistemul central respinge mijlocul de identificare după restabilirea conexiunii. Conveniți cu proprietarul locației expunerea operațională și financiară acceptabilă.
6. Alegeți în mod deliberat modelul de securitate
Întrebați dacă cititorul doar citește un identificator sau efectuează autentificare criptografică folosind mijlocul de identificare. Într-o soluție bazată exclusiv pe UID, acceptarea unui identificator corespunzător nu dovedește posesia unui secret criptografic. Achiziția unui cip cu funcții de securitate aduce valoare doar dacă cititorul și aplicația instalate folosesc acele funcții.
Dacă este necesară autentificarea criptografică a cardului, documentați aplicația acceptată, proprietatea cheilor, procesul de configurare inițială, procedura de înlocuire și responsabilitățile de migrare. Nu includeți secrete în fișierele de predare UID. Ghidul NIST privind securitatea RFID, secțiunea 5.3.1, descrie diferența dintre identificatori și mecanismele de autentificare. Este un ghid fundamental publicat în 2007; utilizați documentația actuală a produselor pentru alegerea algoritmilor și a mecanismelor de gestionare a cheilor acceptate.
Securizați separat conexiunea dintre stație și sistemul central. Actualul Security Operations Guide al OCA, secțiunile 4.2 și 4.4, descrie Security Profile 2 ca TLS cu Basic Authentication și Profile 3 ca TLS cu certificate de client și tratează stocarea datelor de autentificare. Confirmați profilul de transport implementat, validarea certificatelor și gestionarea datelor de autentificare ale stației. Aceste setări protejează o altă conexiune decât legătura card–cititor.
7. Adăugați autorizarea de roaming doar dacă serviciul o cere
O instalație privată la locul de muncă poate avea nevoie doar de registrul de identificatori al propriei platforme. Roamingul introduce o nouă limită între sisteme: operatorul punctelor de încărcare, sau CPO, trebuie să obțină autorizare de la furnizorul relevant de servicii de electromobilitate, sau eMSP, prin integrarea și acordul comercial acceptate.
În OCPI 2.3.0, o înregistrare de token conține identificatorii de țară și de entitate ai furnizorului deținător, UID-ul tokenului, tipul, valabilitatea și politica de includere pe lista de elemente permise. Politica ALLOWED_OFFLINE privește comunicarea dintre CPO și eMSP. Pierderea conexiunii dintre stație și CSMS este o întrerupere separată. Testați ambele limite dacă ambele există.
Modulul Tokens distinge și între un token valid și unul permis într-o anumită locație. Invalidarea este propagată prin actualizarea tokenului cu valid: false; mecanismul nu constă în ștergerea tokenurilor prin acea interfață. Verificați modulul oficial Tokens din OCPI 2.3.0 în raport cu versiunea convenită cu partenerul.
Pentru proiectul-pilot, numiți emitentul și rețeaua participantă, stabiliți traseul de autorizare așteptat și verificați sesiunea și înregistrarea de încărcare rezultate. Utilizarea aceluiași card fizic la mai multe servicii necesită în continuare înregistrările, permisiunile și acordurile corespunzătoare.
8. Validați la punerea în funcțiune întregul ciclu de acces
Folosiți o matrice de testare în care rezultatele așteptate sunt scrise înaintea testului. Executați-o pentru fiecare configurație distinctă de hardware, firmware și sistem central, apoi verificați prin sondaj echipamentele instalate față de configurația aprobată.
| Testare | Dovezi de recepție de păstrat |
|---|---|
| Card autorizat online | Identificator corect, punct de încărcare permis și contul dorit; sesiunea începe conform așteptărilor. |
| Card necunoscut online | Respingere conform așteptărilor; nu pornește o sesiune neintenționată. |
| Mijloc de identificare restricționat sau expirat | Decizia așteptată în locația și la momentul relevante. |
| Oprirea sesiunii | Cardul inițiator și orice card de grup activat deliberat se comportă conform acordului; cardurile fără legătură nu pot opri sesiunea. |
| Cititor comun sau mai mulți conectori | Autorizarea este asociată punctului de încărcare și sesiunii dorite. |
| Conexiunea stației întreruptă | Cardurile folosite anterior, preîncărcate, necunoscute și revocate se comportă conform politicii offline. |
| Conexiune restabilită | Sesiunile offline sunt reconciliate; conflictele de autorizare și sesiunile în curs urmează comportamentul convenit. |
| Repornire după sincronizare | Configurația dorită și starea locală a identificatorilor persistă sau sunt recuperate conform documentației. |
| Facturare și alocare | Identitatea sesiunii, unitățile de energie, marcajele temporale, contul și tariful sau centrul de cost corespund înregistrării așteptate. |
| Card pierdut și înlocuire | Vechiul mijloc de identificare este revocat pe toate traseele relevante de autorizare; înlocuitorul funcționează cu atribuirea dorită. |
Pentru fiecare execuție, păstrați ora, identificatorii stației și conectorului, firmware-ul, referința cardului de test, configurația efectivă, rezultatul așteptat, rezultatul real și înregistrarea tranzacției relevante. Mascați datele personale în dovezile partajate în afara echipei de operare.
Când se pierde un card, notați când a fost primită sesizarea și când fiecare sistem conectat a confirmat modificarea. O stație deconectată nu poate primi imediat o nouă revocare. Expunerea practică depinde de starea de autorizare stocată, de regulile de expirare și de comportamentul la reconectare. Tratați acest interval în procedura de operare.
Diagnosticați o citire eșuată la limita corectă între sisteme
Colectați o încercare eșuată, cu marcajul temporal și referința cardului, apoi examinați dovezile. Aceste verificări restrâng investigația fără a presupune că toate respingerile au aceeași cauză.
| Rezultat observat | Următoarea verificare |
|---|---|
| În diagnosticarea disponibilă nu apare niciun identificator | Confirmați acoperirea diagnosticării, apoi modul cititorului, tehnologia acceptată și funcționarea cu un eșantion verificat. |
| Valoarea raportată diferă de fișierul de import | Comparați ordinea octeților, notația, separatorii și orice transformare a identificatorului; păstrați valorile originale. |
| Sistemul central primește valoarea dorită, dar o respinge | Examinați starea returnată, atribuirea contului, activarea, expirarea și permisiunile de locație. |
| Cardul funcționează online, dar nu în timpul unei întreruperi | Verificați ce mecanism de autorizare locală este implementat, populat și activat pentru acel identificator. |
| Un card revocat funcționează în continuare local | Examinați confirmarea sincronizării, versiunea listei locale, starea memoriei cache și regulile efective de expirare. |
| Sesiunea este atribuită contului greșit | Verificați corespondențele identificatorilor, atribuirile duplicate și înregistrarea tranzacției rezultate înainte de a distribui alte carduri. |
Exemplu de implementare la o bază de flotă
Luați ca exemplu o bază fictivă cu 60 de șoferi, 12 puncte de încărcare și două modele de stații. Operatorul dorește acces atribuit individual șoferilor, limitat la bază, iar șoferii aprobați să poată încărca și în timpul unei întreruperi a sistemului central.
Începeți cu cinci mijloace de identificare de probă. La fiecare model de stație, preluați identificatorul raportat și conveniți corespondența cu fișierul furnizorului. Înregistrați eșantioanele într-un cont-pilot, atribuiți accesul la bază și confirmați centrul de cost prevăzut.
Dacă echipamentele acceptă o listă locală gestionată, preîncărcați identificatorii-pilot și notați versiunea confirmată. Pentru politica propusă, mențineți dezactivată acceptarea identificatorilor necunoscuți offline. Deconectați stația de la CSMS într-un test controlat, apoi încercați un card preîncărcat, unul necunoscut și unul revocat, a cărui stare locală neactualizată este documentată deliberat. Restabiliți conexiunea și verificați actualizarea și înregistrările tranzacțiilor.
Finalizați testele de respingere online, oprire a sesiunii și facturare pe ambele modele. După validarea proiectului-pilot, reconciliați fișierul de producție pentru 60 de carduri cu registrul sistemului central, rezolvați excepțiile și distribuiți cardurile împreună cu o procedură simplă de raportare a pierderii. Repetați testele de recepție relevante după modificări semnificative ale firmware-ului, modului cititorului sau platformei.
Întrebări de clarificat înainte de comandă
Cardurile RFID de încărcare trebuie programate?
Pentru o soluție care citește UID-ul existent al cardului, configurarea poate consta în înregistrarea valorii și atribuirea accesului în platformă. O soluție cu aplicație protejată poate necesita personalizarea cardurilor și configurarea coordonată a cititorului. Specificați fluxul exact al cititorului înainte de a comanda oricare dintre servicii.
Un ecuson de angajat existent poate debloca și o stație de încărcare?
Poate fi posibil dacă cititorul acceptă tehnologia ecusonului, identificatorul necesar este disponibil și stabil, iar platforma permite înregistrarea. Obțineți aprobarea proprietarului sistemului de ecusoane și testați eșantioane reale. Ca exemplu de înrolare specifică unei platforme, documentația Easee pentru conturi și chei locale descrie domenii de înrolare distincte și avertizează asupra identificatorilor care se modifică.
Un singur card va funcționa în orice rețea de încărcare?
Verificați individual rețelele vizate. Posibilitatea citirii fizice, înregistrarea identificatorului, drepturile contului și orice acord de roaming fac parte din criteriile de recepție. Testați rețeaua participantă în loc să deduceți acoperirea din aspectul cardului.
Ce informații trebuie să primească furnizorul de carduri?
Furnizați cerințele cititorului, corespondența aprobată a identificatorilor de probă, schema numerotării vizibile, specificațiile de material și imprimare, cantitatea și formatul convenit de livrare a datelor. Includeți persoana responsabilă de importul în sistemul central și de acceptarea eșantioanelor. Dacă soluția o cere, transferați secretele aplicației printr-un proces securizat de configurare convenit separat.
Pregătiți specificația eșantioanelor pentru implementarea dumneavoastră
Reuniți într-o singură specificație modelul și firmware-ul stației, numele sistemului central și versiunea protocolului, modul necesar de utilizare a mijlocului de identificare, reprezentarea confirmată a identificatorului și politica offline prevăzută. Utilizați laboratorul ChargeRFID pentru date de identificare pentru a analiza predarea datelor și solicitați mostre finisate pentru proiectul-pilot. Aprobați împreună mijlocul fizic de identificare și întregul său flux de acces înainte de lansarea comenzii de producție.
Denumirile companiilor, rețelelor și produselor menționate în acest articol sunt mărci comerciale ale deținătorilor respectivi. Acestea sunt utilizate descriptiv, pentru a identifica sistemele cu care cardurile noastre sunt interoperabile. ChargeRFID este un producător independent, iar acest articol nu afirmă nicio afiliere, parteneriat sau susținere.
Surse primare
Referințe oficiale utilizate pentru verificarea afirmațiilor privind reglementările, protocoalele și cipurile din acest ghid.
- Open Charge Alliance protocol overviewOpen Charge Alliance
- NFC Forum technical overviewNFC Forum
- updated certification programOpen Charge Alliance
- OCPP 2.Lite application note, section COpen Charge Alliance
- official downloads and errataOpen Charge Alliance
- OCPP 1.6 packageOpen Charge Alliance
- OCPP 2.0.1 Edition 4 packageOpen Charge Alliance
- Wallbox activation guide, pages 14 and 20Wallbox
- Wallbox WebAdmin manual, page 23Wallbox
- Microsoft's guidance for preserving identifier dataMicrosoft
- OCTT 2026-02 test cases, sections 2.3.1 and 2.3.2Open Charge Alliance
- RFID security guidance, section 5.3.1NIST
- Security Operations Guide, sections 4.2 and 4.4Open Charge Alliance
- official OCPI 2.3.0 Tokens moduleOCPI specification repository
- Easee account and local-key documentationEasee
Pasul următor
Transformați cercetarea într-o specificație de card.
Comunicați-ne contextul privind cititorul, cipul, datele sau implementarea, iar noi vom identifica deciziile necesare pentru mostre și producție.
Continuați lectura
Articole similare

Carduri RFID de încărcare pentru flote: ghid pentru operațiunile comerciale cu vehicule electrice
Cum funcționează cardurile RFID de încărcare pentru flote în operațiunile comerciale cu vehicule electrice: evidența kWh pentru fiecare vehicul, integrarea OCPP, raportarea specifică programului, gestionarea cheilor criptografice pentru mai multe depouri și ce trebuie specificat la emiterea cardurilor pentru șoferi.

Carduri RFID pentru încărcarea vehiculelor electrice: cum funcționează și cum alegeți unul potrivit
Ce face de fapt un card RFID pentru încărcarea vehiculelor electrice, cum se autentifică la stațiile OCPP și la platformele de roaming, ce tehnologii de cip sunt utilizate și cum alegeți cardul potrivit pentru flote, rețele sau uz personal.