Un card nu creează roaming
Accesul la rețea există numai după ce sunt stabilite conexiunea comercială și distribuirea tokenurilor sau autorizarea.
Program de carduri RFID pentru roaming
Roaming între rețele
Carduri și brelocuri RFID fizice pentru programe de roaming în care înregistrările tokenurilor, formatele identificatorilor și starea pe durata ciclului de viață rămân consecvente în sistemele eMSP, CPO și hub.
Rezultatul programului
Un card sau breloc RFID a cărui înregistrare de token, format de identificator și stare din ciclul de viață rămân consecvente în toate sistemele participante.
Consultați produsul recomandatConceput pentru
eMSP, CPO și platforme de mobilitate care operează roaming bilateral sau prin hub
01
Nivelul de roaming
OCPI 2.2.1 / 2.3.0, OICP sau eMIP
02
Nivelul stației
Cititor + OCPP + sistem central CPO
03
Identitate
Înregistrare de token controlată de emitent
04
Domeniul comercial
Contractele și drepturile de utilizare se află în afara cardului
Model operațional / 01
Urmăriți cardul sau brelocul RFID pe întregul lanț de autorizare.
Cardul fizic este doar una dintre componentele controlate. Comportamentul cititorului, înregistrările din platformă și regulile de operare stabilesc dacă este autorizat contul corect și dacă acesta poate fi urmărit.
Un card sau breloc RFID a cărui înregistrare de token, format de identificator și stare din ciclul de viață rămân consecvente în toate sistemele participante.
- 01
Card sau breloc emis de eMSP
Furnizorul de mobilitate atribuie unui client un card sau un breloc și controlează starea acestuia pe parcursul ciclului de viață.
- 02
Stația de încărcare vizitată
Stația citește cardul sau brelocul și transmite identificatorul către sistemul central al CPO, folosind fluxul de autorizare acceptat.
- 03
Nivelul de autorizare al CPO
CPO verifică o bază locală de tokenuri sau solicită autorizarea prin conexiunea sa de roaming.
- 04
Conexiune bilaterală sau hub de roaming
OCPI, OICP sau eMIP transmit informațiile despre tokenuri, autorizare și sesiunile aferente între părțile contractante.
- 05
Returnarea datelor de sesiune și CDR
Datele de sesiune și înregistrările detaliate ale încărcării (CDR) parcurg înapoi lanțul comercial; cardul este doar elementul care declanșează identificarea.
Matrice de specificații / 02
Decizii de luat înainte de producție.
Un dosar de cerințe pregătit pentru producție precizează ce trebuie decis, cum se va implementa și ce dovezi vor fi acceptate la recepție.
DecizieCe trebuie definitDovezi pentru acceptare
01
Topologia de roaming
Ce trebuie definit
Identificați partenerii bilaterali, conexiunile la hub, mediile și versiunile de protocol.
Dovezi pentru acceptare
Fiecare rută țintă are un responsabil și un endpoint de testare.
02
Proprietatea asupra tokenului
Ce trebuie definit
Definiți emitentul, identificatorii de parte/țară, tipul de token, referința contractului și autoritatea asupra ciclului de viață.
Dovezi pentru acceptare
Tokenul rămâne unic la nivel global în cadrul ecosistemului convenit.
03
Normalizarea UID
Ce trebuie definit
Conveniți reprezentarea hexazecimală sau zecimală, ordinea octeților, completarea (padding), utilizarea majusculelor/minusculelor și lungimea permisă.
Dovezi pentru acceptare
Valoarea returnată de cititor, înregistrarea din CSMS și payloadul de roaming corespund aceleiași valori.
04
Modul de autorizare
Ce trebuie definit
Documentați transmiterea listei de identificatori autorizați, cererile în timp real, memoria cache și comportamentul offline pentru fiecare parc de stații CPO țintă.
Dovezi pentru acceptare
Stările acceptat, blocat, expirat și necunoscut produc rezultatul așteptat.
05
Propagarea stării
Ce trebuie definit
Definiți modul în care tokenurile nou emise, blocate, expirate și înlocuite circulă între părți.
Dovezi pentru acceptare
O modificare de stare ajunge la CPO-ul de test în intervalul operațional convenit.
06
Reconcilierea sesiunilor
Ce trebuie definit
Specificați referințele utilizate pentru reconcilierea înregistrărilor de autorizare, de sesiune și CDR.
Dovezi pentru acceptare
Sesiunile pilot revin la înregistrarea corectă a clientului eMSP, fără date orfane.
07
Gestionarea excepțiilor
Ce trebuie definit
Atribuiți responsabilitatea pentru tokenurile respinse, nepotrivirile cu cititoarele, întreruperile la parteneri și sesiunile contestate.
Dovezi pentru acceptare
Echipa de asistență poate urmări un eșec în jurnalele stației, ale CPO, ale hubului și ale eMSP.
Prevenirea erorilor / 03
Eliminați încă din proiectare punctele frecvente de eșec.
Majoritatea lansărilor eșuate nu se datorează calității tipăririi. Cauzele sunt identificatorii neclari, cititoarele netestate, responsabilitatea incompletă asupra datelor sau controlul slab al ciclului de viață.
Normalizați identificatorii o singură dată
Nepotrivirile privind ordinea octeților, completarea și majusculele/minusculele sunt cauze frecvente ale autorizărilor eșuate; fixați reprezentarea înainte de producție.
Testați stările din ciclul de viață
O primă apropiere reușită a cardului de cititor nu este suficientă. Validați căile de blocare, expirare, înlocuire și reactivare pe aceeași rută.
Nu includeți decontarea în afirmațiile despre carduri
Schimbul de CDR, tarifele și decontarea țin de platformele și contractele de roaming, nu de fabricarea cardurilor și brelocurilor.
Etapele livrării / 04
De la dosarul de cerințe la operarea controlată.
Fiecare etapă ar trebui să se încheie cu dovezi care pot fi analizate de echipele de operațiuni, de platformă și de achiziții.
- 01
Harta topologiei
Documentați emitentul, partenerii, huburile, versiunile de protocol, proprietatea asupra tokenurilor și contactele de asistență.
DoveziMatricea responsabilităților de roaming
- 02
Pilot pentru identificatori
Produceți un set redus cu valori cunoscute și comparați reprezentările din cititor, din CSMS și din roaming.
DoveziTrasabilitatea completă a tokenului
- 03
Testarea stărilor
Verificați scenariile acceptat, necunoscut, blocat, expirat, offline și înlocuire.
DoveziMatricea rezultatelor de autorizare
- 04
Lansarea pe piață
Efectuați lansarea numai pe piețele și pe rutele partenerilor pentru care recepția a fost finalizată.
DoveziRegistrul aprobat al piețelor și partenerilor
- 05
Controlul modificărilor
Gestionați partenerii noi, actualizările de protocol și înlocuirile fără a modifica în mod tacit regulile de identitate fizică.
DoveziÎnregistrare de interoperabilitate versionată
Delimitarea responsabilităților / 05
Separați producția de operarea platformei.
O delimitare precisă împiedică atribuirea către card a unor probleme de configurare, de drepturi de utilizare sau de decontare, care țin de alte sisteme.
ChargeRFID / producător
Controlează materialul aprobat, cipul, antena, grafica, codificarea, datele variabile, controlul calității pe loturi și evidența de producție.
Echipa CPO, eMSP sau CSMS
Definește formatul de identificator acceptat, comportamentul cititorului, importul tokenurilor, stările de autorizare, aplicația de securitate și recepția tehnică.
Proprietarul programului
Răspunde de alocare, activare, contracte, politica de acces, tarife, asistența pentru clienți, aprobarea înlocuirilor și deciziile privind sfârșitul ciclului de viață.
Opțiuni de carduri și brelocuri / 06
Formate fizice de evaluat după clarificarea cerințelor de sistem.
Fluxuri OCPP / idTag / idToken / Formatarea UID
Carduri RFID pentru rețele de încărcare OCPP
Carduri și brelocuri RFID pregătite pentru fluxul de identificare și autorizare utilizat între cititoarele stațiilor de încărcare și sistemele de gestionare a încărcării bazate pe OCPP.
Consultați produsul recomandat
Operațiuni de flotă / Date de tokenuri pentru import în masă / Reaprovizionare
Carduri de încărcare pentru flote de vehicule electrice
Carduri și brelocuri RFID cu marca proprie pentru încărcarea flotelor, cu date unice de token, numerotare pe șofer sau vehicul, import în masă în platformă și reaprovizionare controlată.
Consultați produsul recomandat
PVC reciclat / RFID personalizat / Asociere UID
Carduri de încărcare din PVC reciclat pentru vehicule electrice
Carduri RFID personalizate pentru încărcare, cu corp din PVC reciclat, opțiuni de cip adaptate cititorului, grafică de program și predarea datelor de asociere UID–cont.
Consultați produsul recomandatBibliotecă tehnică / 07
Continuați documentarea pentru implementare.
Aceste surse definesc tehnologia și interfețele operaționale conexe. ChargeRFID produce carduri și brelocuri RFID fizice. Configurarea platformei, contractele de roaming și certificarea stațiilor de încărcare rămân în sarcina operatorilor și furnizorilor relevanți.
Infrastructură pentru vehicule electrice / 6 min de citit
Roaming RFID: cum funcționează un singur card în rețelele de încărcare participante (ghid 2026)
Un singur card RFID, toate rețelele de încărcare. Cum funcționează roamingul pentru vehicule electrice prin OCPI și OICP, de ce șoferii nu mai au nevoie de câte o aplicație pentru fiecare rețea și cum obțin flotele un singur card și o singură factură la peste 1 milion de stații de încărcare în 2026.
Citiți mai mult
Proiecte selectate / 2 min de lectură
Octopus Electroverse — arhivă de carduri de încărcare pentru vehicule electrice
Octopus Electroverse: o evidență discretă a producției unui card de încărcare pentru vehicule electrice din PVC, cu imprimare personalizată.
Citiți mai multReferințe principale pentru implementare
Întrebări despre program / 08
Întrebări pe care echipele de achiziții și cele tehnice le clarifică de obicei.
01Un card nou fabricat va funcționa automat în rețelele de roaming?
Nu. Identificatorul cardului sau al brelocului trebuie înregistrat și autorizat prin conexiunea comercială și tehnică eMSP/CPO. Fabricarea produce suportul fizic; nu creează un contract de roaming și nici dreptul de utilizare a tokenului.
02Care este diferența dintre OCPP și OCPI?
OCPP este în principal protocolul dintre stație și sistemul de gestionare. OCPI conectează CPO și eMSP pentru date de roaming precum locații, tokenuri, sesiuni, tarife și CDR. OICP și eMIP oferă interfețe de roaming alternative.
03Ce versiune OCPI trebuie să accepte cardul?
Cardul nu implementează OCPI. Platformele participante convin asupra versiunii OCPI, în timp ce cardul sau brelocul și identificatorul acestuia trebuie să corespundă cititorului și regulilor pentru tokenuri utilizate de aceste platforme.
04Poate un identificator să fie reprezentat diferit de sisteme diferite?
Da, iar aceasta este o sursă frecventă de erori. Conversia hex/zecimal, ordinea octeților, completarea, zerourile de la început și majusculele/minusculele trebuie fixate în specificația de interfață și verificate cap-coadă.
Alte programe operaționale
Autentificare pentru flote de vehicule
Carduri și brelocuri RFID pentru încărcarea în depou, la locul de muncă și în rețele publice, cu alocare controlată pe șofer sau vehicul, identificatori pregătiți pentru platformă și evidența înlocuirilor.
Programe de carduri și brelocuri pentru CPO și eMSP
Carduri și brelocuri white-label, pregătite în funcție de marca dumneavoastră, formatul identificatorului, importul în platformă, volumul de lansare și fluxul comenzilor repetate.
Acces la locații și pentru membri
Programe de carduri și brelocuri pentru locuri de muncă, depouri, complexe rezidențiale și destinații care necesită acces controlat în funcție de angajat, rezident, vizitator sau cont.
Migrare RFID securizată
O cale controlată de trecere de la carduri sau brelocuri vechi ori bazate doar pe UID la o tehnologie de card adaptată cititoarelor, cu un pilot practic, un plan de date și o reemitere etapizată.
Industria auto și programe premium pentru membri
Carduri și brelocuri personalizate cu marca dumneavoastră pentru predarea vehiculelor, încărcarea la dealeri, programe de loialitate și programe premium pentru membri, cu serializare și prezentare controlate.
Specificație controlată a programului: Carduri RFID pentru rețele de încărcare OCPP
Transmiteți-ne informații despre parcul de cititoare RFID, regulile pentru identificatori, cerințele de securitate, transferul către platformă, volumul și piețele de implementare. Vă vom trimite întrebările necesare pentru mostre și pentru aprobarea producției.