Slik setter du opp RFID-tilgang for næringsladere

For å sette opp RFID-tilgang for næringsladere må du bekrefte at leseren støtter identifikasjonsmediet, hente identifikatoren som laderen faktisk rapporterer, registrere verdien i ladeplattformen, tildele nødvendige tilgangsrettigheter og teste hele ladeøkten. Test deretter hva som skjer når forbindelsen svikter, og når et kort sperres.

Bestill produksjonsserien etter at en representativ prøve har bestått dette forløpet. En vellykket avlesning viser bare en del av resultatet. Godkjenningsprotokollen bør også vise riktig ladepunkt, konto, energiregistrering og oppførsel ved stopp.

Denne veiledningen omhandler tilgangsstyring etter at ladeutstyret er installert og satt i drift av en kvalifisert installatør. Den er beregnet på teamet som kobler fysiske identifikasjonsmedier til et ladestyringssystem.

Forstå hvilket system som tar hver beslutning

Ved nettbasert autorisasjon henter RFID-leseren en identifikator, ladestasjonen sender den til et sentralt ladestyringssystem, CSMS, og plattformen returnerer et autorisasjonsresultat. OCPP regulerer kommunikasjonen mellom stasjonen og styringssystemet. Radiogrensesnittet mellom kort og leser er en egen del av integrasjonen. Se Open Charge Alliances protokolloversikt.

Gi én person ansvar for hvert lag. Kortleverandøren kan levere avtalt fysisk identifikasjonsmedium og identifikatorfil; ladeintegratoren bekrefter leserens oppførsel; plattformoperatøren styrer kontoregistrering og rettigheter. Dokumenter hvem som løser avvik før idriftsettingen starter.

1. Bekreft leserens og autorisasjonens funksjoner

Be om leserspesifikasjonen for nøyaktig ladermodell, maskinvarerevisjon og installert fastvare. Dokumenter hvilke kontaktløse standarder den støtter, hvilken identifikasjonsmodus den bruker, og eventuell konfigurerbar konvertering av identifikatorer. En beskrivelse som «RFID-aktivert» besvarer ikke disse spørsmålene.

NFC bruker 13.56 MHz og omfatter flere kontaktløse teknologier, blant annet ISO/IEC 14443 Type A, Type B og ISO/IEC 15693. Samsvar i frekvens alene er derfor en ufullstendig innkjøpsspesifikasjon. Match den faktiske kortteknologien med leserens implementasjon. NFC Forums tekniske oversikt forklarer de underliggende protokollene.

Avklar deretter hva stasjonen og baksystemet faktisk implementerer:

OCPP-sertifisering må vurderes på funksjonsnivå. OCAs oppdatering fra desember 2025 plasserer Local List Management blant de valgfrie funksjonene i OCPP 2.0.1 Core-profilen. Det oppdaterte sertifiseringsprogrammet garanterer derfor ikke at alle sertifiserte stasjoner støtter lokale lister. OCAs applikasjonsnotat om OCPP 2.Lite, avsnitt C, forklarer også at autorisasjonsmellomlager kan utelates, og at implementasjoner kan støtte ulike autorisasjonsmetoder.

Be om sertifikatets omfang og en Protocol Implementation Conformance Statement, der den finnes, og kontroller dem mot den installerte programvaren. Oppbevar dokumentasjonen sammen med anleggets konfigurasjon.

OCA publiserer for tiden pakker for OCPP 1.6, 2.0.1 og 2.1. Eksemplene nedenfor gjelder spesifikt 1.6 og 2.0.1; bruk tilsvarende spesifikasjon for en 2.1-installasjon. Kontroller offisielle nedlastinger og rettelser ved idriftsetting eller oppgradering.

2. Hent identifikatoren fra den faktiske laderen

Begynn med et lite sett testkort som kan identifiseres enkeltvis. Hold den trykte kortreferansen atskilt fra den elektroniske verdien: et synlig serienummer som CRF-TEST-0042 er nyttig for kundestøtte, men sammenhengen med identifikatoren i baksystemet må dokumenteres.

Disse illustrative nyttelastfragmentene viser en nettbasert OCPP-autorisasjonsforespørsel med en fiktiv identifikator:

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

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

Fragmentene utelater innrammingen av WebSocket-meldinger. De offisielle skjemaene angir maksimalt 20 tegn for idTag i 1.6 og 36 for strengen idToken i 2.0.1; 2.0.1 krever også tokentype. Valider mot OCPP 1.6-pakken eller OCPP 2.0.1 Edition 4-pakken som brukes i integrasjonen.

En lokalt autorisert start kan følge en annen meldingssekvens. Be integratoren angi hvor identifikasjonsmediet og autorisasjonsbeslutningen registreres i denne modusen.

3. Avtal UID-representasjonen før kortimport

For et ISO14443-token anbefaler OCPP 2.0.1 heksadesimale UID-byte med byte 0 først. Oppførselen til eldre produkter må fortsatt kontrolleres: Wallbox' OCPP-aktiveringsveiledning angir heksadesimale verdier i little-endian-rekkefølge uten skilletegn for produktene veiledningen dekker. Dette er en produktspesifikk instruksjon, ikke en universell konverteringsregel. Se OCPP 2.0.1, autorisasjonsavsnitt C.1.1 og Wallbox' aktiveringsveiledning, side 14 og 20.

For denne fiktive sekvensen på sju byte er representasjonene:

Tabellen viser konverteringer, ikke fire utbyttbare verdier for baksystemet. Importer representasjonen integrasjonen krever. Når byte snus, endres rekkefølgen parvis; å snu enkelttegn gir et annet resultat.

Dokumenter koblingen mellom leverandørdata, stasjonsloggen og importfeltet i baksystemet. Ta med bytelengde, heksadesimal eller desimal notasjon, byterekkefølge, skilletegn og enhver uttrykkelig dokumentert konvertering. Bevar den rå kildefilen. Unngå udokumentert avkorting og gjetting på manglende byte.

Kontroller om enheten har innstillinger som omformer identifikatorer. Wallbox eM4 WebAdmin-håndboken inneholder for eksempel valget «Shorten UIDs» og advarer om at autorisasjonsinnstillinger kan endres fra både det lokale grensesnittet og baksystemet. Se Wallbox WebAdmin-håndboken, side 23. Dokumenter den effektive konfigurasjonen etter at begge systemene er tilkoblet.

Importer identifikatorkolonner som tekst i regneark. Excel kan fjerne innledende nuller og begrenser tallpresisjonen til 15 signifikante sifre; desimaleksemplet vårt har 16 sifre. Et visningsformat som brukes etter at data er endret, gjenoppretter ikke originalidentifikatoren. Følg Microsofts veiledning for å bevare identifikatordata.

Bruk ChargeRFIDs UID-konverterer til å undersøke representasjoner og verktøyet for avstemming av identifikatorfiler til å sammenligne produksjons- og baksystemfiler. Bekreft den foreslåtte tilordningen mot en faktisk laderlogg før den brukes på serien.

4. Registrer identifikasjonsmedier og tildel kommersielle rettigheter

Opprett posten gjennom plattformens dokumenterte registrerings- eller importprosess. Knytt den til riktig fører, kjøretøy, avdeling eller kundekonto ut fra hvordan virksomheten tilordner lading.

Dokumenter følgende for hvert identifikasjonsmedium i piloten:

Behandle disse som separate godkjenningsspørsmål. Et identifikasjonsmedium kan finnes i databasen uten tiltenkt stedstillatelse eller kontotilknytning. En vellykket start viser heller ikke at riktig faktureringsopplegg er brukt.

Bruk en registreringsoversikt med seriereferanse, importresultat, avviksårsak og kontrollør. Løs duplikater og motstridende tilordninger før frigivelse. Tilpass UID-overleveringsmalen til plattformens faktiske importkontrakt; eksempelraden er testdata.

Avtal hvem som kan stoppe en økt ved delte kjøretøy. OCAs OCPP 1.6-testtilfeller dekker uttrykkelig stopp med startkortet og stopp med et annet kort som er koblet gjennom en samsvarende overordnet identifikator. Test gruppeoppførselen dere vil aktivere. Se OCTT 2026-02-testtilfellene, avsnitt 2.3.1 og 2.3.2.

5. Fastsett en uttrykkelig policy for frakoblet tilgang

Avgjør om lading skal være mulig når stasjonen ikke når styringssystemet. For et flåtedepot med begrenset tilgang er et fornuftig utgangspunkt å tillate tiltenkte lokalt autoriserte identifikasjonsmedier og avvise ukjente kort under et avbrudd. Bekreft at utstyret kan håndheve policyen før dere baserer driften på den.

Et autorisasjonsmellomlager inneholder autorisasjonsinformasjon fra tidligere utvekslinger. En lokal autorisasjonsliste administreres og synkroniseres fra baksystemet. Dette er to ulike mekanismer. Å tømme den ene viser ikke at den andre er oppdatert. OCPP 1.6 beskriver forholdet i spesifikasjonens avsnitt 3.5.

Dette er eksempler på versjonsspesifikke navn som skal diskuteres med integratoren, ikke en konfigurasjonsfil som skal limes inn i en lader:

Navnene innebærer ikke at alle funksjoner er implementert, aktivert eller skrivbare. OCPP 2.0.1 bruker adressering av komponenter og variabler; enhetsmodellen og det aktuelle brukstilfellet avgjør hvordan hver innstilling virker. Se Edition 4-avsnittene om autorisasjon og refererte variabler.

Dokumenter den lokale listens kapasitet, oppdateringsbekreftelse, utløpshåndtering, bevaring etter omstart og oppførsel når lagringsplassen er full. Test både et kjent identifikasjonsmedium som aldri har vært brukt på stasjonen, og et som allerede er autorisert der. Dette bidrar til å fastslå hvilken lokal mekanisme installasjonen faktisk er avhengig av.

Ta med gjenopprettet forbindelse i testen. Kontroller hvordan frakoblede transaksjoner når baksystemet, hvordan de avstemmes, og hva som skjer med en pågående økt hvis baksystemet avviser identifikasjonsmediet etter at forbindelsen er tilbake. Avtal akseptabel driftsmessig og økonomisk eksponering med anleggseieren.

6. Velg sikkerhetsmodell for identifikasjonsmediet bevisst

Spør om leseren bare leser en identifikator eller utfører kryptografisk autentisering med identifikasjonsmediet. I en løsning som bare bruker UID, viser aksept av en samsvarende identifikator ikke at noen har en kryptografisk hemmelighet. En brikke med sikkerhetsfunksjoner gir bare verdi når den installerte leseren og applikasjonen bruker funksjonene.

Der kryptografisk kortautentisering kreves, må dere dokumentere støttet applikasjon, eierskap til nøkler, klargjøringsprosess, utskiftingsprosedyre og migreringsansvar. Hold hemmeligheter utenfor UID-overleveringsfiler. NISTs RFID-sikkerhetsveiledning, avsnitt 5.3.1, beskriver skillet mellom identifikatorer og autentiseringskontroller. Dette er grunnleggende veiledning publisert i 2007; bruk oppdatert produktdokumentasjon til å velge støttede algoritmer og mekanismer for nøkkelhåndtering.

Sikre forbindelsen mellom stasjonen og baksystemet separat. OCAs gjeldende Security Operations Guide, avsnitt 4.2 og 4.4, beskriver Security Profile 2 som TLS med Basic Authentication og Profile 3 som TLS med klientsertifikater og omtaler lagring av autentiseringsopplysninger. Bekreft transportprofilen som brukes, sertifikatvalideringen og håndteringen av stasjonens autentiseringsopplysninger. Disse innstillingene beskytter en annen forbindelse enn forbindelsen mellom kort og leser.

7. Legg til roamingautorisasjon når tjenesten krever det

En privat arbeidsplassinstallasjon trenger kanskje bare sin egen plattforms register over identifikasjonsmedier. Roaming tilfører en ny grense: ladeoperatøren, CPO, må hente autorisasjon fra den aktuelle leverandøren av e-mobilitetstjenester, eMSP, gjennom den støttede integrasjonen og den kommersielle avtalen.

I OCPI 2.3.0 inneholder en tokenpost eierleverandørens land- og partsidentifikatorer samt tokenets UID, type, gyldighet og policy for tillatelsesliste. Policyen ALLOWED_OFFLINE gjelder kommunikasjonen mellom CPO og eMSP. At en lader mister forbindelsen til CSMS, er et separat avbrudd. Test begge grensene hvis begge finnes.

Tokens-modulen skiller også mellom et gyldig token og et token som er tillatt på et bestemt sted. Ugyldiggjøring videreformidles gjennom et oppdatert token med valid: false; sletting av token gjennom dette grensesnittet er ikke mekanismen. Kontroller den offisielle OCPI 2.3.0 Tokens-modulen mot versjonen dere har avtalt med partneren.

Navngi utsteder og deltakende nettverk i piloten, fastslå forventet autorisasjonsvei og kontroller den resulterende økten og ladeposten. Gjenbruk av samme fysiske kort på tvers av tjenester krever fortsatt riktig registrering, rettigheter og avtaler.

8. Sett hele tilgangslivssyklusen i drift

Bruk en testmatrise med forventede resultater skrevet før testen. Kjør den på hver særskilte kombinasjon av maskinvare, fastvare og baksystem, og ta deretter stikkprøver av det installerte utstyret mot den godkjente konfigurasjonen.

Behold tidspunkt, stasjons- og kontaktidentifikatorer, fastvare, testkortreferanse, effektiv konfigurasjon, forventet og faktisk resultat og relevant transaksjonspost for hver kjøring. Masker personopplysninger i dokumentasjon som deles utenfor driftsteamet.

Når et kort mistes, registrerer dere når meldingen kom, og når hvert tilkoblet system bekreftet endringen. En frakoblet stasjon kan ikke motta en ny sperring umiddelbart. Den praktiske eksponeringen avhenger av lagret autorisasjonsstatus, utløpsregler og oppførsel ved gjenopprettet forbindelse. Håndter dette tidsrommet i driftsprosedyren.

Feilsøk en mislykket avlesning ved riktig grense

Samle inn ett mislykket forsøk med tidsstempel og kortreferanse, og gå deretter gjennom dokumentasjonen. Disse kontrollene snevrer inn undersøkelsen uten å anta at alle avvisninger har samme årsak.

Eksempel på utrulling ved et flåtedepot

Tenk deg et fiktivt depot med 60 førere, 12 ladepunkter og to ladermodeller. Operatøren vil knytte tilgangen til individuelle førere, begrense den til depotet og la godkjente førere lade under et avbrudd i baksystemet.

Start med fem identifikasjonsmedier som prøver. Hent rapportert identifikator fra hver ladermodell, og avtal koblingen til leverandørfilen. Registrer prøvene på en pilotkonto, tildel depottilgang og bekreft tiltenkt kostnadssted.

Hvis utstyret støtter en administrert lokal liste, laster dere inn pilotens identifikasjonsmedier på forhånd og dokumenterer den bekreftede versjonen. Hold ukjente frakoblede identifikasjonsmedier deaktivert for denne foreslåtte policyen. Koble stasjonen fra CSMS i en kontrollert test, og prøv deretter et forhåndsinnlastet kort, et ukjent kort og et sperret kort med en bevisst dokumentert utdatert lokal status. Gjenopprett forbindelsen og verifiser oppdaterings- og transaksjonspostene.

Fullfør testene for avvisning på nett, stopp av økt og fakturering på begge modeller. Når piloten er godkjent, avstemmer dere produksjonsfilen med 60 kort mot baksystemregisteret, løser avvik og deler ut kortene med en enkel prosess for å melde tap. Gjenta relevante godkjenningstester etter vesentlige endringer i fastvare, lesermodus eller plattform.

Spørsmål som må avklares før bestilling

Må RFID-ladekort programmeres?

For en løsning som leser kortets eksisterende UID, kan oppsettet bestå av å registrere verdien og tildele tilgang i plattformen. En løsning som bruker en beskyttet applikasjon, kan kreve kortpersonalisering og samordnet leserkonfigurasjon. Spesifiser det nøyaktige leserforløpet før en av tjenestene bestilles.

Kan et eksisterende ansattkort også gi tilgang til en lader?

Det kan være mulig når leseren støtter kortteknologien, den nødvendige identifikatoren er tilgjengelig og stabil, og plattformen tillater registrering. Innhent godkjenning fra kortsystemets eier og test faktiske prøver. Som eksempel på plattformspesifikk registrering beskriver Easees dokumentasjon om konto og lokale nøkler ulike registreringsomfang og advarer om identifikatorer som endrer seg.

Virker ett kort på alle ladenettverk?

Avklar de tiltenkte nettverkene enkeltvis. Fysisk lesbarhet, registrering av identifikasjonsmediet, kontorettigheter og en eventuell roamingavtale inngår alle i godkjenningskriteriene. Test det deltakende nettverket i stedet for å anta dekning ut fra kortets utseende.

Hva bør kortleverandøren få?

Oppgi leserkrav, godkjent kobling av prøveidentifikatorer, synlig nummereringssystem, material- og trykkspesifikasjon, antall og avtalt format for datalevering. Ta med den som er ansvarlig for import til baksystemet og godkjenning av prøver. Overfør applikasjonshemmeligheter gjennom en særskilt avtalt sikker klargjøringsprosess når løsningen krever det.

Lag en prøvespesifikasjon for installasjonen

Samle ladermodell og fastvare, navn på baksystem og protokollversjon, nødvendig identifikasjonsmodus, bekreftet identifikatorrepresentasjon og tiltenkt frakoblingspolicy i én spesifikasjon. Bruk ChargeRFIDs identifikasjonslaboratorium til å gjennomgå dataoverleveringen og bestill ferdige prøver til piloten. Godkjenn det fysiske identifikasjonsmediet og hele tilgangsforløpet samlet før produksjonsordren frigis.