Wagenparkbeheer

RFID-laadkaarten voor wagenparken: gids voor commerciële EV-operaties

Hoe RFID-laadkaarten voor wagenparken werken voor commerciële EV-operaties: kWh-tracking per voertuig, OCPP-integratie, programmaspecifieke rapportage, sleutelbeheer voor meerdere depots en wat u moet specificeren bij het uitgeven van kaarten aan bestuurders.

Artikelgegevens

Gepubliceerd
2 mei 2026
Leestijd
8 min lezen
Uitgever
ChargeRFID
Terug naar kennisbank

Door ChargeRFID

Beoordelingsmethode: We hebben deze gids getoetst aan de hieronder vermelde primaire bronnen voor regelgeving en protocollen en de primaire bronnen van fabrikanten. De productaanbevelingen weerspiegelen het perspectief van ChargeRFID als fabrikant en dienen te worden getoetst met uw lezer, laadpaal en backend.

RFID-laadkaarten voor wagenparken: gids voor commerciële EV-operaties

Een commercieel wagenpark met elektrische voertuigen verandert de kostenstructuur van het laden. In plaats van één bestuurder die bij een tankstation een eigen creditcard gebruikt, heeft u 50, 500 of 5.000 bestuurders die laden bij depots, openbare laadstations en thuisladers. Elke sessie levert gegevens op over kosten, kWh en fiscaal relevante zaken die correct in de wagenparksoftware moeten worden verwerkt. Met RFID-laadkaarten voor wagenparken worden die gegevens bij de bron vastgelegd.

Deze gids behandelt wat een RFID-laadkaart voor wagenparken anders maakt dan een consumentenkaart, hoe de authenticatie- en rapportageketen werkt en wat u moet specificeren wanneer u kaarten uitgeeft binnen een commercieel EV-programma.

Wat een RFID-laadkaart voor wagenparken anders maakt

Een laadpas biedt een token aan. Of dat token een bestuurder, voertuig, depot, kostenplaats of contract vertegenwoordigt, wordt bepaald door de backends voor het wagenpark en het laden. Eén kaart identificeert niet vanzelf al deze entiteiten tegelijk.

De kaart kan een identificatiemiddel op 13,56 MHz met AES-authenticatie zijn of een andere technologie gebruiken die compatibel is met de lezer. Het belangrijkste verschil zit in de manier waarop de identificator of beveiligde applicatie wordt ingericht en gekoppeld in de backends:

•kWh-tracking per voertuig — de UID van de kaart wordt in het wagenparkbeheersysteem aan een specifiek voertuig gekoppeld, zodat elke laadsessie aan een voertuig kan worden toegewezen.
•Toewijzing aan de bestuurder — in combinatie met voertuigtelematica maakt de kaart het mogelijk energiekosten toe te wijzen aan de bestuurder die op die dag aan het voertuig was toegewezen.
•Autorisatie per depot — groepen in de backend kunnen het gebruik van tokens tot bepaalde depots beperken. Cryptografische sleutels kunnen alleen een extra beveiligingslaag bieden als de kaarten en lezers een beveiligde applicatie gebruiken.
•Fiscaal relevante gegevens — de Britse fiscale behandeling hangt af van het eigendom van het voertuig, de laadlocatie, zakelijk of privégebruik en de berekening van vergoedingen. Sessiegegevens ondersteunen de berekening, maar maken deze op zichzelf niet programmaspecifiek.

Hoe RFID-authenticatie voor wagenparken werkt op OCPP-laadstations

Het autorisatie- en transactieproces hangt af van de OCPP-versie. Een gebruikelijk proces met OCPP 1.6 ziet er als volgt uit:

Wanneer een bestuurder een wagenparkkaart bij een depot of openbaar laadstation aanbiedt:

1.Het laadstation leest de UID uit en stuurt Authorize.req naar het centrale systeem.
2.Het centrale systeem controleert de UID aan de hand van de toestemmingslijst van het wagenpark, vaak gefilterd op depot, bestuurdersgroep of voertuiggroep.
3.Na goedkeuring verstuurt het laadstation StartTransaction met onder meer de connector, idTag, tijdstempel en beginmeterstand.
4.Aan het einde van de sessie verstuurt StopTransaction de transactie-identificator, tijdstempel, eindmeterstand en optionele transactiegegevens. Duur, energieverbruik en een CDR voor facturatie worden door achterliggende systemen berekend of samengesteld; het OCPP 1.6-bericht bevat geen ingebouwde CDR.
5.Het laadbeheersysteem kan de sessiegegevens verrijken en records naar de rapportagebackend van het wagenpark sturen. OCPP 2.x gebruikt het andere TransactionEvent-model in plaats van het paar start- en stopberichten uit OCPP 1.6.

Voor wagenparken die zowel bij depots als bij openbare laadstations laden, levert OCPI-roaming CDR's van externe CPO's via de MSP van het wagenpark aan dezelfde rapportageketen.

Kaartmodellen per voertuig en per bestuurder

De meeste wagenparken kiezen tussen twee modellen:

Kaarten per voertuig blijven bij het voertuig, bijvoorbeeld in het handschoenenkastje of aan een sleutelhanger. Voordelen: eenvoudig voor bestuurders en gemakkelijk opnieuw toe te wijzen wanneer bestuurders wisselen. Nadelen: de kaart kan samen met het voertuig worden gestolen en maakt het niet mogelijk het gedrag van individuele bestuurders afzonderlijk te bepalen.

Kaarten per bestuurder gaan met de bestuurder mee naar verschillende voertuigen. Voordeel: directe toewijzing aan de bestuurder. Nadelen: voor een nauwkeurige toewijzing aan voertuigen en gereden kilometers blijven toewijzings- of telematicagegevens nodig. De fiscale behandeling moet bovendien de toepasselijke HMRC-regels volgen en kan niet alleen op het kaartmodel worden gebaseerd.

Veel grote wagenparken geven beide uit: een kaart per bestuurder voor kostentoewijzing en een sleutelhanger per voertuig als reserve en voor eenvoudige toegang.

Sleutelbeheer voor meerdere depots

Voor wagenparken met meerdere depots kan de backend autorisatie afdwingen op basis van tokengroep, voertuig, bestuurder of locatie. Een identificatiemiddel op 13,56 MHz met AES-authenticatie ondersteunt ook gediversifieerde applicatiesleutels wanneer de gebruikte lezers een beveiligde applicatie authenticeren in plaats van alleen de openbare UID uit te lezen.

Bij een correct ontworpen beveiligde applicatie kunnen afzonderlijke sleuteldomeinen de gevolgen van een gecompromitteerde sleutel beperken. Voor het vervangen van die sleutels blijft een gedocumenteerd proces nodig voor lezers, kaarten, beveiligde modules en de backend. Een autorisatiesysteem op basis van openbare UID's trekt daarentegen afzonderlijke tokens of groepen tokens in de backend in.

Vermijd één gedeelde applicatiesleutel voor het hele wagenpark, maar voeg geen kaartsleutels toe die de lezers van de laadstations en de backend nooit voor authenticatie gebruiken. Stem de beveiligingsmaatregel af op de werkelijke autorisatiearchitectuur.

Rapportage: van OCPP-CDR naar gegevens voor HMRC-processen

De kaart is slechts het beginpunt. De rapportageketen maakt een wagenparkprogramma financieel werkbaar.

Een gebruikelijk Brits wagenparkproces:

1.Bestuurder biedt kaart aan → laadstation autoriseert → sessie loopt → CDR wordt vastgelegd.
2.De CDR wordt verrijkt met metadata over bestuurder, voertuig en depot uit het wagenparkbeheersysteem.
3.De energiekosten worden berekend op basis van het overeengekomen tarief, vaak een tijdsafhankelijk tarief of een tarief waarbij kosten worden doorberekend.
4.Waar nodig worden kilometergegevens en laadlocatiegegevens gecombineerd om de toepasselijke HMRC-regels voor vergoedingen of voordelen toe te passen.
5.De gecontroleerde resultaten kunnen vervolgens processen voor salarisadministratie, onkosten of belastingen ondersteunen, passend bij het eigendom en het gebruik van het voertuig.

De keten van kaart tot rapport moet van begin tot eind controleerbaar zijn. Dat controlespoor komt normaal gesproken uit meterstanden van laadstations, OCPP-gebeurtenissen, sessiegegevens en CDR's van CPO's en eMSP's, tariefgegevens, tokenkoppelingen en wagenparkmetadata. De transactie-MAC-functies van een identificatiemiddel op 13,56 MHz met AES-authenticatie maken of valideren niet automatisch de laad-CDR in de backend, zeker niet wanneer een laadstation alleen de UID van de kaart uitleest.

Roaming voor laden bij depots en openbare laadstations

De meeste commerciële wagenparken kunnen niet uitsluitend bij depots laden. Bestuurders die lange afstanden afleggen, bezorgdiensten met wisselende routes en wagenparken met een thuislaadregeling hebben allemaal via dezelfde kaart toegang tot openbare laadnetwerken nodig.

Daarom zijn tokenpublicatie en actieve roamingovereenkomsten belangrijk. Een wagenparkkaart die door een eMSP wordt uitgegeven, kan werken bij gecontracteerde CPO's die via een hub of een directe OCPI/OICP-verbinding bereikbaar zijn. Baseer het bereik op de actuele lijst van contractueel aangesloten netwerken van de eMSP. Het totale aantal aangesloten laadpunten van een platform garandeert niet dat een bepaalde kaart overal wordt geaccepteerd.

De CDR's gaan terug naar de MSP van het wagenpark. Als het contract een opslagmodel gebruikt, worden de bedragen opnieuw berekend. Vervolgens worden de CDR's in dezelfde rapportageketen verwerkt als sessies bij depots.

Wat u moet specificeren bij het uitgeven van RFID-laadkaarten voor wagenparken

Een voorbeeld van een inkoopchecklist:

•Chip en applicatie: technologie die compatibel is met de lezer; gebruik sleutels voor identificatiemiddelen op 13,56 MHz met AES-authenticatie alleen wanneer de lezer de beveiligde applicatie authenticeert
•Materiaal: gerecycled PVC, de meest voorkomende optie, of FSC-hout voor ESG-gerichte programma's
•Vormfactor: ISO 7810 ID-1-kaarten plus sleutelhangers voor bevestiging aan voertuigsleutels
•Bedrukking: fullcolour met voertuig-/bestuurder-ID, wagenparklogo en lasergravering tegen manipulatie
•Codering: vooraf gecodeerde UID, idTag afgestemd op het MSP-formaat en een depotspecifieke gediversifieerde sleutel
•Roaming: tokenpublicatie en actieve eMSP–CPO-overeenkomsten voor de vereiste netwerken
•Heruitgiftebeleid: een proces voor verlies, intrekking, vervanging en synchronisatie op basis van pilotgegevens
•Commerciële voorwaarden: actueel minimumaantal, prijs, levertijd en vervangingsvoorwaarden in een schriftelijke leveranciersofferte

Veelgemaakte fouten in wagenparkkaartprogramma's

•Kaarten uitgeven voordat de MSP-integratie actief is — bestuurders bieden hun kaart aan en worden geweigerd omdat de idTag nog niet is geregistreerd.
•Eén gedeelde applicatiesleutel voor het hele wagenpark — vergroot onnodig de gevolgen van een gecompromitteerde sleutel wanneer beveiligde applicaties daadwerkelijk worden gebruikt.
•Geen proces voor heruitgifte — hierdoor blijven verloren kaarten, vervangende tokens en synchronisatie met de backend onbeheerd.
•Blinde vlekken bij openbaar laden — ervan uitgaan dat 'we gewoon meer laadstations bij depots installeren' in plaats van roaming vanaf het begin in te plannen.
•Een niet-passend UID-formaat — verschillende MSP's verwachten verschillende idTag-formaten, zoals 4-byte, 7-byte, hexadecimaal of decimaal; stem dit af voordat u 5.000 kaarten codeert.

Hoe nu verder?

Een programma met RFID-laadkaarten voor wagenparken vraagt om een specificatie op vier punten: chipbeveiliging, codeerformaat, roamingbereik en rapportage-integratie. Als die goed zijn geregeld, worden de kaarten onzichtbare infrastructuur: bestuurders bieden hun kaart aan, er wordt stroom geleverd en de gegevens worden correct in de wagenparkadministratie verwerkt.

Bekijk onze EV-laadkaarten van gerecycled PVC en FSC-hout of lees hoe wij wagenparkkaartprogramma's ontwikkelden met een geselecteerd EV-laadprogramma en een geselecteerd wagenparklaadprogramma. Neem contact met ons op over het laadprogramma van uw wagenpark — wij helpen u de juiste kaart te specificeren en deze af te stemmen op uw MSP.

Bedrijfs-, netwerk- en productnamen in dit artikel zijn handelsmerken van hun respectieve eigenaren. Ze worden beschrijvend gebruikt om systemen te benoemen waarmee onze kaarten samenwerken. ChargeRFID is een onafhankelijke fabrikant en dit artikel doet geen uitspraak over enige band, samenwerking of goedkeuring.

Primaire bronnen

Officiële bronnen die zijn gebruikt om de uitspraken over regelgeving, protocollen en chips in deze gids te controleren.

Delen:

Volgende stap

Zet de onderzoeksresultaten om in een kaartspecificatie.

Deel de context van de lezer, chip, gegevens of uitrol. Wij bepalen welke beslissingen nodig zijn voor monsters en productie.