RFID-toegang instellen voor zakelijke laadstations

Om RFID-toegang voor zakelijke laadstations in te stellen, controleert u of de lezer uw identificatiemiddel ondersteunt, legt u de identificator vast die het laadstation daadwerkelijk doorgeeft, registreert u die waarde in het laadplatform, kent u de benodigde toegangsrechten toe en test u de volledige laadsessie. Test vervolgens wat er gebeurt bij verbindingsverlies en wanneer een kaart wordt ingetrokken.

Bestel de productiebatch nadat een representatief monster deze procedure met goed gevolg heeft doorlopen. Een geslaagde kaartaanbieding bevestigt slechts een deel van het resultaat. Uw acceptatieverslag zou ook het juiste laadpunt, het juiste account, de juiste energieregistratie en het juiste stopgedrag moeten aantonen.

Deze handleiding behandelt toegangsbeheer nadat de laadapparatuur door een bevoegde installateur is geïnstalleerd en in bedrijf is gesteld. Ze is bedoeld voor het team dat fysieke identificatiemiddelen aan een laadbeheersysteem koppelt.

Begrijp welk systeem welke beslissing neemt

Bij online autorisatie leest de RFID-lezer een identificator uit, stuurt het laadstation die door naar een laadstationbeheersysteem, of CSMS, en geeft het platform een autorisatieresultaat terug. OCPP regelt de communicatie tussen het station en dat beheersysteem. De radio-interface tussen kaart en lezer vormt een afzonderlijk onderdeel van de integratie. Zie het protocoloverzicht van de Open Charge Alliance.

Wijs voor elke laag één verantwoordelijke aan. Een kaartleverancier kan het afgesproken fysieke identificatiemiddel en identificatorbestand leveren; de laadstationintegrator bevestigt het gedrag van de lezer; de platformbeheerder beheert accountregistratie en rechten. Leg vóór de inbedrijfstelling vast wie afwijkingen oplost.

1. Controleer de mogelijkheden voor lezen en autorisatie

Vraag de lezerspecificatie op voor het exacte laadstationmodel, de hardwarerevisie en de geïnstalleerde firmware. Noteer de ondersteunde contactloze standaarden, de gebruikte identificatiemodus en eventuele instelbare identificatorconversies. Een omschrijving als ‘geschikt voor RFID’ beantwoordt deze vragen niet.

NFC werkt op 13,56 MHz en omvat verschillende contactloze technologieën, waaronder ISO/IEC 14443 Type A, Type B en ISO/IEC 15693. Alleen een overeenkomende frequentie is dus geen volledige inkoopspecificatie. Stem de daadwerkelijke kaarttechnologie en lezerimplementatie op elkaar af. Het technische overzicht van het NFC Forum legt deze onderliggende protocollen uit.

Stel vervolgens vast wat het station en de backend daadwerkelijk ondersteunen:

OCPP-certificering moet op functieniveau worden beoordeeld. In de update van december 2025 plaatst OCA Local List Management bij de optionele functies binnen het OCPP 2.0.1 Core-profiel. Het bijgewerkte certificeringsprogramma garandeert dus niet dat elk gecertificeerd station lokale lijsten ondersteunt. Ook de OCPP 2.Lite-toepassingsnotitie, sectie C van OCA legt uit dat een autorisatiecache kan ontbreken en dat implementaties verschillende autorisatiemethoden kunnen ondersteunen.

Vraag waar beschikbaar de certificeringsscope en de Protocol Implementation Conformance Statement op en vergelijk deze met de geïnstalleerde software. Bewaar dit bewijs bij de locatieconfiguratie.

OCA publiceert momenteel pakketten voor OCPP 1.6, 2.0.1 en 2.1. De onderstaande voorbeelden hebben specifiek betrekking op 1.6 en 2.0.1; gebruik voor een 2.1-installatie de bijbehorende specificatie. Controleer bij inbedrijfstelling of upgrades de officiële downloads en errata.

2. Leg de identificator van het daadwerkelijke laadstation vast

Begin met een kleine set herkenbare testkaarten. Houd de gedrukte kaartreferentie gescheiden van de elektronische waarde: een zichtbaar serienummer zoals CRF-TEST-0042 is nuttig voor ondersteuning, maar de relatie met de backendidentificator moet worden gedocumenteerd.

Dit zijn illustratieve payloadfragmenten voor een online OCPP-autorisatieverzoek met een fictieve identificator:

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

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

Deze fragmenten bevatten geen WebSocket-berichtomkadering. De officiële schema's bepalen een maximum van 20 tekens voor idTag in 1.6 en 36 voor de tekenreeks idToken in 2.0.1; 2.0.1 vereist ook het tokentype. Valideer aan de hand van het OCPP 1.6-pakket of OCPP 2.0.1 Edition 4-pakket dat voor uw integratie wordt gebruikt.

Een lokaal geautoriseerde start kan een andere berichtvolgorde volgen. Laat de integrator aangeven waar het identificatiemiddel en de autorisatiebeslissing voor die modus worden geregistreerd.

3. Spreek de UID-representatie af voordat u kaarten importeert

Voor een ISO14443-token beveelt OCPP 2.0.1 hexadecimale UID-bytes aan met byte 0 voorop. Bestaand productgedrag moet nog steeds worden gecontroleerd: de OCPP-activeringshandleiding van Wallbox schrijft voor de daarin behandelde producten little-endian hexadecimale waarden zonder scheidingstekens voor. Dat is een productspecifieke instructie, geen universele conversieregel. Zie OCPP 2.0.1, autorisatiesectie C.1.1 en de Wallbox-activeringshandleiding, pagina's 14 en 20.

Voor deze fictieve reeks van zeven bytes zijn de representaties:

De tabel toont transformaties, geen vier onderling uitwisselbare backendwaarden. Importeer de representatie die de integratie vereist. Bytes omkeren verandert de volgorde per tekenpaar; afzonderlijke tekens omkeren geeft een ander resultaat.

Leg de koppeling tussen leveranciersgegevens, het stationlog en het backendimportveld schriftelijk vast. Neem de lengte in bytes, hexadecimale of decimale notatie, bytevolgorde, scheidingstekens en expliciet gedocumenteerde transformaties op. Bewaar het onbewerkte bronbestand. Vermijd ongedocumenteerde afkapping en raad ontbrekende bytes niet.

Controleer apparaatinstellingen die identificatoren transformeren. De Wallbox eM4 WebAdmin-handleiding bevat bijvoorbeeld een optie ‘Shorten UIDs’ en waarschuwt dat autorisatie-instellingen zowel via de lokale interface als via de backend kunnen worden gewijzigd. Zie de Wallbox WebAdmin-handleiding, pagina 23. Leg de effectieve configuratie vast nadat beide systemen zijn verbonden.

Importeer identificatorkolommen in spreadsheets als tekst. Excel kan voorloopnullen verwijderen en beperkt de numerieke precisie tot 15 significante cijfers; ons decimale voorbeeld telt 16 cijfers. Een weergaveopmaak toepassen nadat gegevens zijn gewijzigd, herstelt de oorspronkelijke identificator niet. Volg Microsofts richtlijnen voor het behouden van identificatorgegevens.

Gebruik de ChargeRFID UID-converter om representaties te bekijken en het hulpmiddel voor identificatorbestandsvergelijking om productie- en backendbestanden te vergelijken. Bevestig de voorgestelde koppeling met een echt laadstationlog voordat u deze op de batch toepast.

4. Registreer identificatiemiddelen en ken commerciële rechten toe

Maak de registratie van het identificatiemiddel aan volgens het gedocumenteerde aanmeld- of importproces van het platform. Koppel deze aan de bedoelde bestuurder, het voertuig, de afdeling of het klantaccount, afhankelijk van hoe uw organisatie laadsessies toerekent.

Leg voor elk identificatiemiddel in de pilot vast:

Behandel dit als afzonderlijke acceptatievragen. Een identificatiemiddel kan in de database staan zonder de bedoelde locatierechten of accountkoppeling te hebben. Een geslaagde start bewijst evenmin dat de juiste facturatieafspraken zijn toegepast.

Gebruik een registratieregister met batchreferentie, importresultaat, uitzonderingsreden en beoordelaar. Los dubbele waarden en tegenstrijdige toewijzingen vóór vrijgave op. Pas het UID-overdrachtssjabloon aan de daadwerkelijke importspecificatie van uw platform aan; de voorbeeldrij bevat testgegevens.

Spreek voor gedeelde voertuigen af wie een sessie mag stoppen. De OCPP 1.6-testgevallen van OCA behandelen expliciet stoppen met de startkaart en stoppen met een andere kaart die via een overeenkomende bovenliggende identificator is gekoppeld. Test het groepsgedrag dat u wilt inschakelen. Zie de OCTT 2026-02-testgevallen, secties 2.3.1 en 2.3.2.

5. Stel een expliciet beleid voor offline toegang in

Bepaal of laden moet doorgaan wanneer het station zijn beheersysteem niet kan bereiken. Voor een afgeschermd wagenparkdepot is een bruikbaar uitgangspunt om tijdens een storing de bedoelde lokaal geautoriseerde identificatiemiddelen toe te laten en onbekende kaarten te weigeren. Controleer of de apparatuur dit beleid kan uitvoeren voordat u erop vertrouwt.

Een autorisatiecache bewaart autorisatiegegevens die tijdens eerdere uitwisselingen zijn verkregen. Een lokale autorisatielijst wordt vanuit de backend beheerd en gesynchroniseerd. Het zijn verschillende mechanismen. Het wissen van de ene bewijst niet dat de andere is bijgewerkt. OCPP 1.6 beschrijft hun samenhang in sectie 3.5 van de specificatie.

Dit zijn voorbeelden van versiegebonden namen om met de integrator te bespreken, geen configuratiebestand om in een laadstation te plakken:

Deze namen verklaren niet dat elke functie is geïmplementeerd, ingeschakeld of wijzigbaar. OCPP 2.0.1 gebruikt adressering op basis van componenten en variabelen; het apparaatmodel en de toepasselijke gebruikssituatie bepalen hoe elke instelling werkt. Zie de autorisatiesecties en secties over bijbehorende variabelen in Edition 4.

Noteer de capaciteit van de lokale lijst, updatebevestiging, afhandeling van verval, behoud na herstart en gedrag bij volle opslag. Test zowel een bekend identificatiemiddel dat nooit eerder op het station is gebruikt als een dat daar al is geautoriseerd. Zo stelt u vast op welk lokaal mechanisme de installatie daadwerkelijk steunt.

Neem herstel van de verbinding op in de test. Controleer hoe offline transacties de backend bereiken, hoe ze worden afgestemd en wat er met een lopende sessie gebeurt als de backend het identificatiemiddel na verbindingsherstel weigert. Spreek met de locatie-eigenaar de aanvaardbare operationele en financiële blootstelling af.

6. Kies het beveiligingsmodel voor identificatiemiddelen bewust

Vraag of de lezer alleen een identificator uitleest of cryptografische authenticatie met het identificatiemiddel uitvoert. Bij een ontwerp op basis van alleen UID bewijst acceptatie van een overeenkomende identificator niet dat een cryptografisch geheim aanwezig is. Een chip met beveiligingsmogelijkheden aanschaffen heeft alleen waarde wanneer de geïnstalleerde lezer en applicatie die mogelijkheden gebruiken.

Wanneer cryptografische kaartauthenticatie vereist is, documenteert u de ondersteunde applicatie, het sleuteleigendom, het inrichtingsproces, de vervangingsprocedure en de migratieverantwoordelijkheden. Houd geheimen buiten UID-overdrachtsbestanden. De RFID-beveiligingsrichtlijn van NIST, sectie 5.3.1, beschrijft het verschil tussen identificatoren en authenticatiemaatregelen. Deze basisrichtlijn is in 2007 gepubliceerd; gebruik actuele productdocumentatie om ondersteunde algoritmen en sleutelbeheermechanismen te kiezen.

Beveilig de verbinding tussen station en backend afzonderlijk. OCA's actuele Security Operations Guide, secties 4.2 en 4.4, beschrijft Security Profile 2 als TLS met Basic Authentication en Profile 3 als TLS met certificaten aan de clientzijde, en behandelt de opslag van authenticatiegegevens. Controleer het gebruikte transportprofiel, de certificaatvalidatie en het beheer van stationgegevens voor authenticatie. Deze instellingen beschermen een andere verbinding dan die tussen kaart en lezer.

7. Voeg roamingautorisatie alleen toe als de dienst dit vereist

Een particuliere installatie op het werk heeft mogelijk alleen het identificatiemiddelenregister van het eigen platform nodig. Roaming voegt een extra grens toe: de laadpuntexploitant, of CPO, moet via de ondersteunde integratie en commerciële afspraken autorisatie verkrijgen van de betreffende aanbieder van elektromobiliteitsdiensten, of eMSP.

In OCPI 2.3.0 bevat een tokenregistratie de land- en partij-identificatoren van de eigenaar-provider, een token-UID, type, geldigheid en beleid voor toelating via een whitelist. Het beleid ALLOWED_OFFLINE betreft de communicatie tussen CPO en eMSP. Een laadstation dat de verbinding met het CSMS verliest, vormt een afzonderlijke storing. Test beide grenzen als beide bestaan.

De Tokens-module onderscheidt ook een geldig token van een token dat op een specifieke locatie is toegestaan. Ongeldigverklaring wordt doorgegeven via een bijgewerkt token met valid: false; tokens via die interface verwijderen is niet het mechanisme. Controleer de officiële OCPI 2.3.0 Tokens-module aan de hand van de met uw partner afgesproken versie.

Benoem voor de pilot de uitgever en het deelnemende netwerk, leg het verwachte autorisatiepad vast en controleer de resulterende sessie en laadregistratie. Dezelfde fysieke kaart voor verschillende diensten gebruiken vereist nog steeds de juiste registratie, rechten en overeenkomsten.

8. Test de volledige toegangscyclus bij inbedrijfstelling

Gebruik een testmatrix met vooraf vastgelegde verwachte resultaten. Voer deze uit voor elke afzonderlijke combinatie van hardware, firmware en backendconfiguratie en controleer daarna steekproefsgewijs of het geïnstalleerde laadstationsbestand met die goedgekeurde configuratie overeenkomt.

Bewaar per uitvoering het tijdstip, station- en connectoridentificatoren, firmware, testkaartreferentie, effectieve configuratie, verwacht resultaat, werkelijk resultaat en relevante transactieregistratie. Scherm persoonsgegevens af in bewijs dat buiten het operationele team wordt gedeeld.

Leg bij kaartverlies vast wanneer de melding binnenkwam en wanneer elk verbonden systeem de wijziging bevestigde. Een niet-verbonden station kan een nieuwe intrekking niet onmiddellijk ontvangen. De praktische blootstelling hangt af van de opgeslagen autorisatiestatus, vervalregels en het gedrag bij verbindingsherstel. Neem dat tijdsinterval op in de operationele procedure.

Onderzoek een mislukte kaartaanbieding op de juiste grens

Verzamel één mislukte poging met tijdstempel en kaartreferentie en loop vervolgens de bewijsstukken na. Deze controles bakenen het onderzoek af zonder aan te nemen dat elke weigering dezelfde oorzaak heeft.

Voorbeelduitrol voor een wagenparkdepot

Neem een fictief depot met 60 bestuurders, 12 laadpunten en twee laadstationmodellen. De exploitant wil toegang per bestuurder toerekenen, beperken tot het depot en goedgekeurde bestuurders tijdens een backendstoring laten laden.

Begin met vijf identificatiemiddelen als monster. Leg bij elk laadstationmodel de doorgegeven identificator vast en spreek de koppeling met het leveranciersbestand af. Registreer de monsters in een pilotaccount, ken depottoegang toe en bevestig de bedoelde kostenplaats.

Als de apparatuur een beheerde lokale lijst ondersteunt, laadt u de pilotmiddelen vooraf in en noteert u de bevestigde versie. Houd onbekende offline identificatiemiddelen voor dit voorgestelde beleid uitgeschakeld. Verbreek tijdens een gecontroleerde test de verbinding tussen station en CSMS en probeer vervolgens een vooraf geladen kaart, een onbekende kaart en een ingetrokken kaart met een bewust gedocumenteerde verouderde lokale status. Herstel de verbinding en controleer de update- en transactieregistraties.

Voltooi de tests voor online weigering, sessiestop en facturatie op beide modellen. Zodra de pilot slaagt, vergelijkt u het productiebestand met 60 kaarten met het backendregister, lost u uitzonderingen op en deelt u de kaarten uit met een eenvoudig meldproces voor kaartverlies. Herhaal de relevante acceptatietests na wezenlijke wijzigingen in firmware, lezermodus of platform.

Vragen die u vóór het bestellen moet beantwoorden

Moeten RFID-laadpassen worden geprogrammeerd?

Bij een ontwerp dat de bestaande UID van de kaart leest, kan de inrichting bestaan uit het registreren van die waarde en het toekennen van toegang in het platform. Een ontwerp met een beveiligde applicatie kan kaartpersonalisatie en afgestemde lezerconfiguratie vereisen. Leg de exacte lezerprocedure vast voordat u een van beide diensten bestelt.

Kan een bestaande personeelspas ook een laadstation vrijgeven?

Dat kan mogelijk als de lezer de pastechnologie ondersteunt, de benodigde identificator beschikbaar en stabiel is en het platform registratie toestaat. Vraag goedkeuring van de eigenaar van het passysteem en test echte monsters. Als voorbeeld van platformspecifieke registratie beschrijft de Easee-documentatie over accounts en lokale sleutels verschillende registratiebereiken en waarschuwt zij voor veranderende identificatoren.

Werkt één kaart op elk laadnetwerk?

Stel de beoogde netwerken afzonderlijk vast. Fysieke leesbaarheid, registratie van het identificatiemiddel, accountrechten en eventuele roamingovereenkomsten maken allemaal deel uit van de acceptatiecriteria. Test het deelnemende netwerk in plaats van dekking uit het uiterlijk van de kaart af te leiden.

Wat moet de kaartleverancier ontvangen?

Geef de lezervereisten, de goedgekeurde identificatorkoppeling van de monsters, het zichtbare nummeringsschema, de materiaal- en drukspecificatie, de hoeveelheid en het afgesproken gegevensformaat door. Vermeld wie verantwoordelijk is voor backendimport en monsteracceptatie. Draag applicatiegeheimen via een afzonderlijk afgesproken beveiligd inrichtingsproces over wanneer het ontwerp daarom vraagt.

Stel een monsterspecificatie voor uw uitrol op

Breng laadstationmodel en firmware, backendnaam en protocolversie, vereiste identificatiemodus, bevestigde identificatorrepresentatie en beoogd offlinebeleid samen in één specificatie. Gebruik het ChargeRFID-identificatiemiddelenlab om de gegevensoverdracht te beoordelen en vraag afgewerkte monsters aan voor uw pilot. Keur het fysieke identificatiemiddel en de volledige toegangsprocedure samen goed voordat u de productieorder vrijgeeft.