Sådan opsætter du RFID-adgang til erhvervsladere

For at opsætte RFID-adgang til erhvervsladere skal du bekræfte, at læseren understøtter dit adgangsmiddel, registrere den identifikator, laderen faktisk rapporterer, oprette værdien i ladeplatformen, tildele de nødvendige adgangsrettigheder og teste hele ladesessionen. Test derefter, hvad der sker, når forbindelsen svigter, og når et kort spærres.

Bestil produktionsserien, når en repræsentativ prøve har bestået dette forløb. En vellykket kortaflæsning dokumenterer kun en del af resultatet. Godkendelsesprotokollen bør også vise det korrekte ladepunkt, den korrekte konto, energiregistreringen og adfærden ved stop.

Denne vejledning dækker adgangsstyring, efter at ladeudstyret er installeret og idriftsat af en kvalificeret installatør. Den er beregnet til det team, der forbinder fysiske adgangsmidler med et ladestyringssystem.

Forstå, hvilket system der træffer hver beslutning

Ved onlineautorisation henter RFID-læseren en identifikator, ladestationen sender den til et centralt ladestyringssystem, CSMS, og platformen returnerer et autorisationsresultat. OCPP regulerer kommunikationen mellem stationen og styringssystemet. Radioforbindelsen mellem kort og læser er en separat del af integrationen. Se Open Charge Alliances protokoloversigt.

Udpeg én ansvarlig for hvert lag. Kortleverandøren kan levere det aftalte fysiske adgangsmiddel og identifikatorfilen; ladeintegratoren bekræfter læserens adfærd; platformsoperatøren styrer kontoregistrering og rettigheder. Dokumentér, hvem der løser en uoverensstemmelse, før idriftsættelsen begynder.

1. Bekræft læserens og autorisationens funktioner

Bed om læserspecifikationen for den præcise ladermodel, hardwarerevision og installerede firmware. Registrér de understøttede kontaktløse standarder, det anvendte identifikationsprincip og eventuel konfigurerbar konvertering af identifikatorer. En beskrivelse som »RFID-kompatibel« besvarer ikke disse spørgsmål.

NFC anvender 13.56 MHz og omfatter flere kontaktløse teknologier, herunder ISO/IEC 14443 Type A, Type B og ISO/IEC 15693. Samme frekvens er derfor ikke en tilstrækkelig indkøbsspecifikation. Match den faktiske kortteknologi med læserens implementering. NFC Forums tekniske oversigt forklarer de underliggende protokoller.

Afklar derefter, hvad stationen og backenden faktisk implementerer:

OCPP-certificering skal læses på funktionsniveau. OCA's opdatering fra december 2025 placerer Local List Management blandt de valgfrie funktioner i OCPP 2.0.1 Core-profilen. Det opdaterede certificeringsprogram betyder derfor ikke, at alle certificerede stationer garanteret understøtter lokale lister. OCA's applikationsnote om OCPP 2.Lite, afsnit C, forklarer også, at en autorisationscache kan udelades, og at implementeringer kan understøtte forskellige autorisationsmetoder.

Bed om certifikatets dækningsområde og en Protocol Implementation Conformance Statement, hvis den findes, og kontrollér dem mod den installerede software. Gem dokumentationen sammen med anlæggets konfiguration.

OCA udgiver i øjeblikket pakker til OCPP 1.6, 2.0.1 og 2.1. Eksemplerne nedenfor gælder specifikt 1.6 og 2.0.1; brug den tilsvarende specifikation til en 2.1-installation. Kontrollér officielle downloads og rettelsesblade ved idriftsættelse eller opgradering.

2. Registrér identifikatoren fra den faktiske lader

Begynd med et lille sæt testkort, der kan identificeres enkeltvis. Hold den trykte kortreference adskilt fra den elektroniske værdi: et synligt serienummer som CRF-TEST-0042 er nyttigt til support, men sammenhængen med backendidentifikatoren skal dokumenteres.

Følgende illustrative nyttelastfragmenter viser en onlineforespørgsel om OCPP-autorisation med en fiktiv identifikator:

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

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

Fragmenterne udelader WebSocket-meddelelsernes indramning. De officielle skemaer angiver højst 20 tegn for idTag i 1.6 og 36 for strengen idToken i 2.0.1; 2.0.1 kræver også tokentypen. Validér mod den OCPP 1.6-pakke eller OCPP 2.0.1 Edition 4-pakke, der bruges til integrationen.

En lokalt autoriseret start kan følge en anden meddelelsessekvens. Bed integratoren udpege, hvor adgangsmidlet og autorisationsbeslutningen registreres i denne tilstand.

3. Aftal UID-repræsentationen før kortimport

For et ISO14443-token anbefaler OCPP 2.0.1 hexadecimale UID-bytes med byte 0 først. Ældre produkters adfærd skal stadig kontrolleres: Wallbox' OCPP-aktiveringsvejledning angiver hexadecimale værdier i little-endian-rækkefølge uden separatorer for de produkter, vejledningen dækker. Det er en produktspecifik anvisning, ikke en universel konverteringsregel. Se OCPP 2.0.1, autorisationsafsnit C.1.1 og Wallbox' aktiveringsvejledning, side 14 og 20.

For denne fiktive sekvens på syv bytes er repræsentationerne:

Tabellen viser konverteringer, ikke fire indbyrdes udskiftelige backendværdier. Importér den repræsentation, integrationen kræver. Når bytes vendes, ændres rækkefølgen parvis; vender du de enkelte tegn, får du et andet resultat.

Dokumentér sammenhængen mellem leverandørdata, stationslog og backendens importfelt. Medtag bytelængde, hexadecimal eller decimal notation, byterækkefølge, separatorer og enhver udtrykkeligt dokumenteret konvertering. Bevar den rå kildefil. Undgå udokumenteret afkortning og gæt på manglende bytes.

Kontrollér, om enheden har indstillinger, der omdanner identifikatorer. Wallbox eM4 WebAdmin-manualen indeholder eksempelvis indstillingen »Shorten UIDs« og advarer om, at autorisationsindstillinger kan ændres både i den lokale brugerflade og fra backenden. Se Wallbox WebAdmin-manualen, side 23. Registrér den effektive konfiguration, når begge systemer har oprettet forbindelse.

Importér identifikatorkolonner som tekst i regneark. Excel kan fjerne foranstillede nuller og begrænser talpræcisionen til 15 betydende cifre; vores decimaleksempel har 16 cifre. Et visningsformat anvendt efter en dataændring genskaber ikke den oprindelige identifikator. Følg Microsofts vejledning om bevaring af identifikatordata.

Brug ChargeRFID's UID-konverter til at undersøge repræsentationer og værktøjet til afstemning af identifikatorfiler til at sammenligne produktions- og backendfiler. Bekræft den foreslåede mapping mod en faktisk laderlog, før du anvender den på serien.

4. Registrér adgangsmidler og tildel kommercielle rettigheder

Opret posten via platformens dokumenterede registrerings- eller importproces. Knyt den til den tilsigtede fører, bil, afdeling eller kundekonto ud fra, hvordan virksomheden fordeler opladningen.

Registrér følgende for hvert adgangsmiddel i piloten:

Behandl disse som særskilte godkendelsesspørgsmål. Et adgangsmiddel kan stå i databasen uden den tilsigtede stedstilladelse eller kontotilknytning. En vellykket start dokumenterer heller ikke, at den korrekte afregningsaftale er anvendt.

Brug en registreringsoversigt med seriereference, importresultat, undtagelsesårsag og kontrollant. Afklar dubletter og modstridende tildelinger før frigivelse. Tilpas UID-overdragelsesskabelonen til platformens faktiske importkontrakt; eksempelrækken er testdata.

Aftal, hvem der må stoppe en session ved delte køretøjer. OCA's OCPP 1.6-testcases dækker udtrykkeligt stop med startkortet og stop med et andet kort, der er forbundet via en matchende overordnet identifikator. Test den gruppeadfærd, I vil aktivere. Se OCTT 2026-02-testcases, afsnit 2.3.1 og 2.3.2.

5. Fastlæg en udtrykkelig politik for offlineadgang

Beslut, om opladning skal kunne fortsætte, når stationen ikke kan nå sit styringssystem. For et flådedepot med begrænset adgang er et fornuftigt udgangspunkt at tillade de tilsigtede lokalt autoriserede adgangsmidler og afvise ukendte kort under et udfald. Bekræft, at udstyret kan håndhæve politikken, før I baserer driften på den.

En autorisationscache indeholder autorisationsoplysninger fra tidligere udvekslinger. En lokal autorisationsliste administreres og synkroniseres fra backenden. Det er to forskellige mekanismer. At rydde den ene dokumenterer ikke, at den anden er opdateret. OCPP 1.6 beskriver sammenhængen i specifikationens afsnit 3.5.

Her er eksempler på versionsspecifikke navne, som skal drøftes med integratoren, ikke en konfigurationsfil, der skal indsættes i en lader:

Navnene betyder ikke, at alle funktioner er implementeret, aktiveret eller skrivbare. OCPP 2.0.1 anvender adressering af komponenter og variabler; enhedsmodellen og den relevante brugssituation bestemmer, hvordan hver indstilling virker. Se Edition 4-afsnittene om autorisation og refererede variabler.

Registrér den lokale listes kapacitet, opdateringskvittering, udløbshåndtering, bevarelse efter genstart og adfærd, når lageret er fuldt. Test både et kendt adgangsmiddel, der aldrig har været brugt på stationen, og et, der allerede er autoriseret der. Det hjælper med at fastslå, hvilken lokal mekanisme installationen faktisk benytter.

Medtag genoprettelse af forbindelsen i testen. Kontrollér, hvordan offlinetransaktioner når backenden og afstemmes, og hvad der sker med en igangværende session, hvis backenden afviser dens adgangsmiddel efter genoprettet forbindelse. Aftal den acceptable driftsmæssige og økonomiske eksponering med anlæggets ejer.

6. Vælg adgangsmidlets sikkerhedsmodel bevidst

Spørg, om læseren blot læser en identifikator eller udfører kryptografisk autentifikation med adgangsmidlet. I en løsning, der kun bruger UID, dokumenterer accept af en matchende identifikator ikke besiddelse af en kryptografisk hemmelighed. En chip med sikkerhedsfunktioner giver kun værdi, når den installerede læser og applikation bruger dem.

Hvor kryptografisk kortautentifikation er nødvendig, skal I dokumentere den understøttede applikation, ejerskab til nøgler, klargøringsprocessen, udskiftningsproceduren og ansvaret for migrering. Hold hemmeligheder ude af UID-overdragelsesfiler. NIST's RFID-sikkerhedsvejledning, afsnit 5.3.1, beskriver forskellen mellem identifikatorer og autentifikationskontroller. Det er grundlæggende vejledning fra 2007; brug aktuel produktdokumentation til at vælge understøttede algoritmer og nøglehåndteringsmekanismer.

Sikr forbindelsen mellem station og backend separat. OCA's aktuelle Security Operations Guide, afsnit 4.2 og 4.4, beskriver Security Profile 2 som TLS med Basic Authentication og Profile 3 som TLS med klientcertifikater og behandler opbevaring af autentifikationsoplysninger. Bekræft den installerede transportprofil, certifikatvalideringen og håndteringen af stationens autentifikationsoplysninger. Indstillingerne beskytter en anden forbindelse end forbindelsen mellem kort og læser.

7. Tilføj roamingautorisation, når tjenesten kræver det

En privat arbejdspladsinstallation behøver muligvis kun sin egen platforms register over adgangsmidler. Roaming tilføjer en ny grænse: ladeoperatøren, CPO, skal indhente autorisation fra den relevante udbyder af e-mobilitetstjenester, eMSP, via den understøttede integration og kommercielle aftale.

I OCPI 2.3.0 indeholder en tokenpost ejerudbyderens lande- og partsidentifikatorer samt tokenets UID, type, gyldighed og politik for tilladelseslisten. Politikken ALLOWED_OFFLINE vedrører kommunikationen mellem CPO og eMSP. At en lader mister forbindelsen til CSMS, er et separat udfald. Test begge grænser, hvis begge findes.

Tokens-modulet skelner også mellem et gyldigt token og et token, der er tilladt på et bestemt sted. Ugyldiggørelse videreformidles via et opdateret token med valid: false; sletning af tokens via denne grænseflade er ikke mekanismen. Kontrollér det officielle OCPI 2.3.0 Tokens-modul mod den version, I har aftalt med partneren.

Navngiv udsteder og deltagende netværk i piloten, fastlæg den forventede autorisationsvej, og kontrollér den resulterende session og laderegistrering. Genbrug af samme fysiske kort på tværs af tjenester kræver stadig korrekt registrering, rettigheder og aftaler.

8. Idriftsæt hele adgangslivscyklussen

Brug en testmatrix med forventede resultater skrevet før testen. Kør den på hver særskilt hardware-, firmware- og backendkonfiguration, og stikprøvekontrollér derefter det installerede udstyr mod den godkendte konfiguration.

Gem tidspunkt, stations- og stikidentifikatorer, firmware, testkortreference, effektiv konfiguration, forventet resultat, faktisk resultat og relevant transaktionsregistrering for hver kørsel. Maskér personoplysninger i dokumentation, der deles uden for driftsteamet.

Når et kort mistes, skal I registrere, hvornår anmeldelsen kom, og hvornår hvert tilsluttet system kvitterede for ændringen. En frakoblet station kan ikke straks modtage en ny spærring. Den praktiske eksponering afhænger af den gemte autorisationsstatus, udløbsreglerne og adfærden ved genoprettet forbindelse. Håndtér dette tidsrum i driftsproceduren.

Fejlsøg en mislykket kortaflæsning ved den rette grænse

Indsaml ét mislykket forsøg med tidsstempel og kortreference, og gennemgå derefter dokumentationen. Disse kontroller indsnævrer undersøgelsen uden at antage, at alle afvisninger har samme årsag.

Eksempel på udrulning i et flådedepot

Forestil dig et fiktivt depot med 60 førere, 12 ladepunkter og to ladermodeller. Operatøren ønsker, at adgang tilskrives de enkelte førere, begrænses til depotet, og at godkendte førere kan oplade under et backendudfald.

Begynd med fem prøveadgangsmidler. Registrér den rapporterede identifikator på hver ladermodel, og aftal mappingen til leverandørfilen. Registrér prøverne på en pilotkonto, tildel depotadgang, og bekræft det tilsigtede omkostningssted.

Hvis udstyret understøtter en administreret lokal liste, forudindlæses pilotens adgangsmidler, og den kvitterede version registreres. Hold ukendte offlineadgangsmidler deaktiveret for denne foreslåede politik. Afbryd stationens forbindelse til CSMS i en kontrolleret test, og prøv derefter et forudindlæst kort, et ukendt kort og et spærret kort med en bevidst dokumenteret forældet lokal status. Genopret forbindelsen, og verificér opdaterings- og transaktionsregistreringerne.

Afslut test af onlineafvisning, sessionsstop og afregning på begge modeller. Når piloten er godkendt, afstemmes produktionsfilen med 60 kort mod backendregistret, undtagelser afklares, og kortene uddeles med en enkel procedure for anmeldelse af mistede kort. Gentag de relevante godkendelsestest efter væsentlige ændringer af firmware, læsertilstand eller platform.

Spørgsmål, der skal afklares før bestilling

Skal RFID-ladekort programmeres?

For en løsning, der læser kortets eksisterende UID, kan opsætningen bestå i at registrere værdien og tildele adgang i platformen. En løsning med en beskyttet applikation kan kræve kortpersonalisering og koordineret læserkonfiguration. Specificér det præcise læserforløb, før en af ydelserne bestilles.

Kan et eksisterende medarbejderkort også give adgang til en lader?

Det kan være muligt, hvis læseren understøtter kortets teknologi, den nødvendige identifikator er tilgængelig og stabil, og platformen tillader registrering. Indhent godkendelse fra ejeren af kortsystemet, og test faktiske prøver. Som eksempel på platformsspecifik registrering beskriver Easees dokumentation om konto og lokale nøgler forskellige registreringsomfang og advarer om skiftende identifikatorer.

Virker ét kort på alle ladenetværk?

Afklar de tilsigtede netværk enkeltvis. Fysisk læsbarhed, registrering af adgangsmidlet, kontorettigheder og en eventuel roamingaftale indgår alle i godkendelseskriterierne. Test det deltagende netværk frem for at antage dækning ud fra kortets udseende.

Hvad skal kortleverandøren modtage?

Oplys læserkrav, godkendt mapping af prøveidentifikatorer, synligt nummereringssystem, materiale- og trykspecifikation, antal og aftalt format for datalevering. Angiv den ansvarlige for backendimport og prøveaccept. Overfør applikationshemmeligheder gennem en særskilt aftalt sikker klargøringsproces, hvis løsningen kræver det.

Udarbejd en prøvespecifikation til installationen

Saml ladermodel og firmware, backendnavn og protokolversion, påkrævet identifikationstilstand, bekræftet identifikatorrepræsentation og tilsigtet offlinepolitik i én specifikation. Brug ChargeRFID's adgangsmiddellaboratorium til at gennemgå dataoverdragelsen, og bestil færdige prøver til piloten. Godkend det fysiske adgangsmiddel og hele adgangsforløbet samlet, før produktionsordren frigives.