Operațiuni de flotă

Carduri RFID de încărcare pentru flote: ghid pentru operațiunile comerciale cu vehicule electrice

Cum susțin cardurile RFID de încărcare pentru flote alocarea vehiculelor, integrarea OCPP, evidențele relevante din punct de vedere fiscal, autorizarea în mai multe depouri și emiterea către șoferi.

Detaliile articolului

Publicat
2 mai 2026
Actualizat
10 iulie 2026
Timp de citire
8 min de lectură
Editor
ChargeRFID
Înapoi la resurse

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.

Carduri RFID de încărcare pentru flote: ghid pentru operațiunile comerciale cu vehicule electrice

Operarea unei flote comerciale de vehicule electrice schimbă economia încărcării. În loc de un singur șofer care plătește cu un card de credit personal la o stație de alimentare, aveți 50, 500 sau 5.000 de șoferi care încarcă în depouri, la stații publice și la stații de încărcare de acasă — fiecare sesiune generând costuri, kWh și date relevante fiscal, care trebuie să ajungă corect în software-ul de gestionare a flotei. Cardurile RFID de încărcare pentru flote sunt modul în care aceste date sunt capturate la sursă.

Acest ghid prezintă ce diferențiază un card RFID de încărcare pentru flote de un card pentru consumatori, cum funcționează lanțul de autentificare și raportare și ce trebuie specificat la emiterea cardurilor într-un program comercial de vehicule electrice.

Ce diferențiază un card RFID de încărcare pentru flote

Un card de încărcare transmite un token. Dacă acel token reprezintă un șofer, un vehicul, un depou, un centru de cost sau un contract este stabilit de sistemele centrale ale flotei și de cele de încărcare. Un singur card nu identifică în mod inerent toate aceste entități simultan.

Cardul poate fi un suport de identificare la 13,56 MHz cu autentificare AES sau poate folosi o altă tehnologie compatibilă cu cititorul. Distincția importantă constă în modul în care identificatorul sau aplicația sa protejată sunt provizionate și mapate în sistemele centrale:

•Monitorizarea kWh pe fiecare vehicul — UID-ul cardului este asociat unui anumit vehicul în sistemul de gestionare a flotei, astfel încât fiecare sesiune de încărcare poate fi alocată unui vehicul.
•Atribuirea pe șofer — în combinație cu telematica vehiculului, cardul permite flotei să atribuie șoferului alocat vehiculului respectiv în ziua respectivă cheltuielile cu energia.
•Autorizarea pe depou — grupurile din sistemul central pot restricționa tokenurile în funcție de depou; cheile criptografice pot adăuga un nivel suplimentar doar acolo unde cardurile și cititoarele folosesc o aplicație protejată.
•Evidențe relevante din punct de vedere fiscal — tratamentul în Regatul Unit depinde de proprietatea asupra vehiculului, de locul de încărcare, de utilizarea în scop de serviciu sau personal și de modul de calcul al rambursării. Înregistrările sesiunilor susțin calculul, dar nu îl fac, prin ele însele, specific programului.

Cum funcționează autentificarea RFID pentru flote la stațiile OCPP

Fluxul de autorizare și de tranzacție depinde de versiunea OCPP. Un traseu tipic în OCPP 1.6 arată astfel:

Atunci când un șofer apropie un card de flotă de cititorul unei stații dintr-un depou sau al unei stații publice:

1.Stația extrage UID-ul și trimite `Authorize.req` către sistemul central (Central System).
2.Sistemul central verifică UID-ul în lista de identificatori autorizați a flotei (adesea filtrată pe depou, grup de șoferi sau grup de vehicule).
3.După aprobare, stația trimite `StartTransaction` cu câmpuri care includ conectorul, idTag-ul, marcajul de timp și valoarea inițială a contorului.
4.La finalul sesiunii, `StopTransaction` transmite identificatorul tranzacției, marcajul de timp, valoarea finală a contorului și, opțional, datele tranzacției. Durata, energia și un CDR de facturare sunt calculate sau compilate de sistemele din aval; acestea nu reprezintă un CDR inclus în mesajul OCPP 1.6.
5.Sistemul de gestionare a încărcării poate îmbogăți datele sesiunii și poate trimite înregistrările către sistemul central de raportare al flotei. OCPP 2.x folosește un model diferit, `TransactionEvent`, în locul perechii de mesaje start/stop din OCPP 1.6.

Pentru flotele care combină încărcarea în depou cu cea publică, roamingul OCPI transmite CDR-urile de la CPO-urile externe, prin MSP-ul flotei, către același flux de raportare.

Carduri alocate vehiculului vs. carduri alocate șoferului

Majoritatea flotelor aleg între două arhitecturi:

Cardurile alocate vehiculului rămân în vehicul (în torpedou sau atașate de un breloc). Avantaje: experiență simplă pentru șofer, realocare ușoară atunci când șoferii fac schimb de vehicule. Dezavantaje: sunt furate odată cu vehiculul și nu permit izolarea comportamentului fiecărui șofer.

Cardurile alocate șoferului îl însoțesc pe șofer de la un vehicul la altul. Avantaje: atribuire directă la nivel de șofer. Dezavantaje: alocarea exactă pe vehicul și pe distanța parcursă necesită în continuare date de alocare sau de telematică, iar tratamentul fiscal trebuie să respecte regulile HMRC aplicabile, nu doar modelul de card.

Multe flote mari le emit pe amândouă — un card alocat șoferului pentru repartizarea costurilor și un breloc RFID alocat vehiculului pentru redundanță și acces facil.

Gestionarea cheilor pentru mai multe depouri

Pentru flotele cu mai multe depouri, autorizarea poate fi aplicată în sistemul central pe grup de tokenuri, vehicul, șofer sau locație. Suportul de identificare la 13,56 MHz cu autentificare AES acceptă și chei de aplicație diversificate, atunci când cititoarele implementate autentifică o aplicație protejată, în loc să citească doar UID-ul public.

Cu o aplicație protejată proiectată corect, domeniile de chei separate pot limita amploarea compromiterii unei chei. Rotirea acestor chei necesită totuși un proces documentat pentru cititoare, carduri, modulele securizate și sistemul central; o schemă de autorizare bazată pe UID-ul public revocă, în schimb, tokenuri individuale sau grupate în sistemul central.

Evitați o singură cheie de aplicație partajată pentru întreaga flotă, dar nu adăugați pe carduri chei pe care cititoarele stațiilor și sistemul central nu le autentifică niciodată. Adaptați mecanismul de control la arhitectura reală de autorizare.

Raportare: de la CDR-ul OCPP la rezultate pregătite pentru HMRC

Cardul este doar punctul de intrare. Lanțul de raportare este cel care face ca un program de flotă să funcționeze din punct de vedere financiar.

Un flux de lucru tipic pentru o flotă din Regatul Unit:

1.Șoferul apropie cardul de cititor → stația autorizează → sesiunea se desfășoară → CDR-ul este înregistrat.
2.CDR-ul este completat cu metadatele privind șoferul, vehiculul și depoul din sistemul de gestionare a flotei.
3.Costul energiei este calculat pe baza tarifului contractat (adesea diferențiat pe intervale orare sau cu refacturare la cost).
4.Datele privind distanța parcursă și locul de încărcare sunt combinate, acolo unde este necesar, pentru a aplica tratamentul HMRC relevant privind rambursarea sau beneficiile.
5.Rezultatele verificate pot susține apoi procesele de salarizare, de decontare a cheltuielilor sau fiscale adecvate tipului de proprietate și de utilizare a vehiculului.

Lanțul de la card la raport trebuie să poată fi auditat cap-coadă. Această pistă de audit provine, de regulă, din valorile contorului stației, evenimentele OCPP, înregistrările de sesiune și CDR-urile CPO/eMSP, datele tarifare, maparea tokenurilor și metadatele flotei. Funcțiile MAC pentru tranzacții ale suportului de identificare la 13,56 MHz cu autentificare AES nu creează și nu validează automat CDR-ul de încărcare din sistemul central, mai ales atunci când stația de încărcare citește doar UID-ul cardului.

Roaming pentru încărcarea mixtă: în depou și publică

Majoritatea flotelor comerciale nu pot funcționa doar cu încărcare în depou. Șoferii pe distanțe lungi, operatorii de livrare pe ultimul kilometru cu rute variabile și orice flotă cu politici de încărcare acasă au nevoie de acces la rețelele publice cu același card.

Aici contează publicarea tokenurilor și acordurile de roaming active. Un card de flotă emis de un eMSP poate funcționa la CPO-urile contractate, accesate printr-o platformă de roaming sau printr-o conexiune directă OCPI/OICP. Acoperirea trebuie stabilită pe baza listei actuale a rețelelor contractate de eMSP; numărul total de puncte conectate la o platformă nu garantează că un anumit card este acceptat peste tot.

CDR-urile revin la MSP-ul flotei, sunt retarifate dacă contractul folosește un model cu adaos și ajung în același flux de raportare ca sesiunile din depou.

Ce trebuie specificat la emiterea cardurilor RFID de încărcare pentru flote

Un exemplu de listă de verificare pentru achiziții:

•Cip și aplicație: tehnologie compatibilă cu cititorul; folosiți chei pentru suportul de identificare la 13,56 MHz cu autentificare AES doar acolo unde cititorul autentifică aplicația protejată
•Material: PVC reciclat (cel mai frecvent) sau lemn FSC pentru programele orientate spre ESG
•Format: carduri ISO 7810 ID-1, plus brelocuri RFID pentru atașare la vehicul
•Imprimare: policromă, cu identificatorul vehiculului/șoferului, logoul flotei și gravură laser antimanipulare
•Codificare: UID precodificat, idTag aliniat la formatul MSP-ului, cheie diversificată specifică fiecărui depou
•Roaming: publicarea tokenurilor și acorduri eMSP–CPO active pentru rețelele necesare
•Politica de reemitere: flux de lucru pentru pierdere, revocare, înlocuire și sincronizare, stabilit pe baza datelor din proiectul-pilot
•Aspecte comerciale: cantitatea minimă de comandă, prețul, termenul de producție și condițiile de înlocuire actuale, într-o ofertă scrisă a furnizorului

Greșeli frecvente în programele de carduri pentru flote

•Emiterea cardurilor înainte ca integrarea cu MSP-ul să fie funcțională — șoferii apropie cardul de cititor și sunt respinși, deoarece idTag-ul nu este încă înregistrat.
•O singură cheie de aplicație comună pentru întreaga flotă — extinde inutil impactul unei compromiteri atunci când aplicațiile protejate sunt efectiv utilizate.
•Lipsa unui proces de reemitere — cardurile pierdute, tokenurile de înlocuire și sincronizarea cu sistemul central rămân negestionate.
•Puncte oarbe la încărcarea publică — presupunerea că „vom instala pur și simplu mai multe stații de încărcare în depou”, în loc ca roamingul să fie inclus în proiect încă din prima zi.
•Format UID nepotrivit — MSP-uri diferite așteaptă formate idTag diferite (4 octeți, 7 octeți, hexazecimal vs. zecimal); aliniați acest aspect înainte de a codifica 5.000 de carduri.

Pașii următori

Un program de carduri RFID pentru încărcarea flotei se specifică pe patru axe: securitatea cipului, formatul de codificare, acoperirea prin roaming și integrarea raportării. Dacă acestea sunt corect definite, cardurile devin o infrastructură invizibilă — șoferii apropie cardul de cititor, energia circulă, iar datele ajung corect în evidențele contabile ale flotei.

Consultați cardurile noastre de încărcare pentru vehicule electrice din PVC reciclat și lemn FSC sau citiți cum am construit programe de carduri pentru flote cu un program selectat de încărcare a vehiculelor electrice și un program selectat de încărcare pentru flote. Discutați cu noi despre programul de încărcare al flotei dumneavoastră — vă ajutăm să specificați cardul potrivit și să îl aliniați cu MSP-ul dumneavoastră.

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.

Distribuiți:

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.