Så inför du RFID-åtkomst för kommersiella elbilsladdare

För att införa RFID-åtkomst för kommersiella elbilsladdare behöver du kontrollera att läsaren stöder ditt identifieringsmedium, fånga den identifierare som laddaren faktiskt rapporterar, registrera värdet i laddplattformen, tilldela rätt behörigheter och testa hela laddsessionen. Testa sedan vad som händer när anslutningen bryts och när ett kort spärras.

Beställ produktionsserien först när ett representativt prov har klarat detta arbetsflöde. En lyckad blippning visar bara en del av resultatet. Acceptansprotokollet bör också visa rätt laddpunkt, konto, energiregistrering och beteende vid avslut.

Den här guiden behandlar åtkomsthantering efter att laddutrustningen har installerats och driftsatts av en kvalificerad installatör. Den riktar sig till teamet som kopplar fysiska identifieringsmedier till ett laddhanteringssystem.

Förstå vilket system som fattar varje beslut

Vid auktorisering online hämtar RFID-läsaren en identifierare, laddstationen skickar den till ett centralt laddhanteringssystem, CSMS, och plattformen returnerar ett auktoriseringsresultat. OCPP reglerar kommunikationen mellan stationen och hanteringssystemet. Radiogränssnittet mellan kort och läsare är en separat del av integrationen. Se Open Charge Alliances protokollöversikt.

Utse en ansvarig person för varje lager. Kortleverantören kan tillhandahålla överenskommet fysiskt identifieringsmedium och identifierarfil; laddintegratören bekräftar läsarens beteende; plattformsoperatören styr kontoregistrering och behörigheter. Dokumentera vem som löser en avvikelse innan driftsättningen börjar.

1. Bekräfta läsarens och auktoriseringens funktioner

Begär läsarspecifikationen för exakt laddarmodell, hårdvarurevision och installerad firmware. Dokumentera vilka kontaktlösa standarder den stöder, vilket identifieringsläge den använder och eventuell konfigurerbar omvandling av identifierare. En beskrivning som ”RFID-aktiverad” besvarar inte dessa frågor.

NFC använder 13.56 MHz och omfattar flera kontaktlösa tekniker, däribland ISO/IEC 14443 typ A, typ B och ISO/IEC 15693. Enbart samma frekvens är därför en ofullständig inköpsspecifikation. Matcha den faktiska korttekniken med läsarens implementation. NFC Forums tekniska översikt förklarar de underliggande protokollen.

Fastställ därefter vad stationen och backend faktiskt implementerar:

OCPP-certifiering måste granskas på funktionsnivå. I OCA:s uppdatering från december 2025 är Local List Management en valfri funktion inom profilen OCPP 2.0.1 Core. Det uppdaterade certifieringsprogrammet innebär alltså inte att varje certifierad station garanterat stöder lokala listor. OCA:s applikationsnot om OCPP 2.Lite, avsnitt C, förklarar också att en auktoriseringscache kan utelämnas och att implementationer kan stödja olika auktoriseringsmetoder.

Begär certifikatets omfattning och, där den finns, en Protocol Implementation Conformance Statement. Kontrollera dem mot den installerade programvaran. Spara underlaget tillsammans med anläggningens konfiguration.

OCA publicerar för närvarande paket för OCPP 1.6, 2.0.1 och 2.1. Exemplen nedan gäller specifikt 1.6 och 2.0.1; använd motsvarande specifikation för en 2.1-installation. Kontrollera officiella nedladdningar och rättelser vid driftsättning eller uppgradering.

2. Fånga identifieraren från den faktiska laddaren

Börja med ett litet antal identifierbara testkort. Håll den tryckta kortreferensen åtskild från det elektroniska värdet: ett synligt serienummer som CRF-TEST-0042 är användbart för support, men dess koppling till backendidentifieraren måste dokumenteras.

Följande illustrativa meddelandefragment visar en auktoriseringsbegäran online via OCPP med en fiktiv identifierare:

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

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

Fragmenten utelämnar WebSocket-meddelandenas inramning. De officiella schemana anger högst 20 tecken för idTag i 1.6 och 36 för strängen idToken i 2.0.1; 2.0.1 kräver även tokentyp. Validera mot det OCPP 1.6-paket eller OCPP 2.0.1 Edition 4-paket som används i integrationen.

En lokalt auktoriserad start kan följa en annan meddelandesekvens. Be integratören ange var identifieringsmediet och auktoriseringsbeslutet registreras i det läget.

3. Kom överens om UID-representationen före kortimporten

För en ISO14443-token rekommenderar OCPP 2.0.1 hexadecimala UID-byte med byte 0 först. Äldre produkters beteende måste ändå kontrolleras: Wallbox OCPP-aktiveringsguide anger hexadecimala värden i little-endian-ordning utan avskiljare för de produkter guiden omfattar. Det är en produktspecifik instruktion, inte en allmän omvandlingsregel. Se OCPP 2.0.1, auktoriseringsavsnitt C.1.1 och Wallbox aktiveringsguide, sidorna 14 och 20.

För denna fiktiva sjubytessekvens blir representationerna:

Tabellen visar omvandlingar, inte fyra utbytbara backendvärden. Importera den representation som integrationen kräver. Att vända byteordningen ändrar ordningen parvis; att vända enskilda tecken ger ett annat resultat.

Dokumentera mappningen mellan leverantörsdata, stationslogg och backendens importfält. Ange bytelängd, hexadecimal eller decimal notation, byteordning, avskiljare och varje uttryckligen dokumenterad omvandling. Bevara den råa källfilen. Undvik odokumenterad trunkering och gissa inte saknade byte.

Kontrollera om enheten har inställningar som omvandlar identifierare. Wallbox eM4 WebAdmin-handbok innehåller exempelvis alternativet ”Shorten UIDs” och varnar för att auktoriseringsinställningar kan ändras både lokalt och från backend. Se Wallbox WebAdmin-handbok, sidan 23. Dokumentera den gällande konfigurationen efter att båda systemen har anslutits.

Importera identifierarkolumner som text i kalkylblad. Excel kan ta bort inledande nollor och begränsar talprecisionen till 15 signifikanta siffror; vårt decimalexempel har 16 siffror. Ett visningsformat som tillämpas efter att data har ändrats återställer inte originalidentifieraren. Följ Microsofts anvisningar för att bevara identifierardata.

Använd ChargeRFID:s UID-omvandlare för att granska representationer och verktyget för avstämning av identifierarfiler för att jämföra produktions- och backendfiler. Bekräfta den föreslagna mappningen mot en verklig laddarlogg innan den tillämpas på serien.

4. Registrera identifieringsmedier och tilldela kommersiella behörigheter

Skapa posten genom plattformens dokumenterade registrerings- eller importprocess. Koppla den till avsedd förare, fordon, avdelning eller kundkonto beroende på hur verksamheten hänför laddningen.

Dokumentera följande för varje identifieringsmedium i piloten:

Behandla dessa som separata acceptansfrågor. Ett identifieringsmedium kan finnas i databasen utan avsedd platsbehörighet eller kontokoppling. En lyckad start visar inte heller att rätt debiteringsupplägg har tillämpats.

Använd en registreringsjournal med seriereferens, importresultat, orsak till avvikelse och granskare. Lös dubbletter och motstridiga tilldelningar före utlämning. Anpassa UID-överlämningsmallen till plattformens faktiska importkontrakt; exempelraden är testdata.

För delade fordon behöver ni komma överens om vem som får avsluta en session. OCA:s testfall för OCPP 1.6 omfattar uttryckligen stopp med startkortet och stopp med ett annat kort kopplat genom en matchande överordnad identifierare. Testa det gruppbeteende ni avser att aktivera. Se OCTT 2026-02-testfallen, avsnitt 2.3.1 och 2.3.2.

5. Ange en uttrycklig policy för offlineåtkomst

Bestäm om laddning ska vara möjlig när stationen inte når sitt hanteringssystem. För en fordonsdepå med begränsat tillträde är en rimlig utgångspunkt att tillåta avsedda lokalt auktoriserade identifieringsmedier och neka okända kort under avbrott. Bekräfta att utrustningen kan genomföra policyn innan ni förlitar er på den.

En auktoriseringscache lagrar auktoriseringsinformation från tidigare utbyten. En lokal auktoriseringslista hanteras och synkroniseras från backend. Det är skilda mekanismer. Att tömma den ena visar inte att den andra har uppdaterats. OCPP 1.6 beskriver förhållandet i specifikationens avsnitt 3.5.

Detta är exempel på versionsspecifika namn att diskutera med integratören, inte en konfigurationsfil att klistra in i laddaren:

Namnen innebär inte att varje funktion är implementerad, aktiverad eller skrivbar. OCPP 2.0.1 adresserar komponenter och variabler; enhetsmodellen och det aktuella användningsfallet avgör hur varje inställning fungerar. Se auktoriseringsavsnitten och avsnitten om refererade variabler i Edition 4.

Dokumentera den lokala listans kapacitet, kvittens på uppdateringar, hantering av utgången giltighet, beständighet efter omstart och beteende när lagringen är full. Testa både ett känt identifieringsmedium som aldrig har använts på stationen och ett som redan har auktoriserats där. Det hjälper er att fastställa vilken lokal mekanism installationen faktiskt förlitar sig på.

Ta med återanslutning i testet. Kontrollera hur offlinetransaktioner når backend, hur de stäms av och vad som händer med en pågående session om backend nekar dess identifieringsmedium efter återanslutning. Kom överens med anläggningsägaren om acceptabel operativ och ekonomisk exponering.

6. Välj säkerhetsmodell för identifieringsmediet medvetet

Fråga om läsaren enbart läser en identifierare eller utför kryptografisk autentisering med identifieringsmediet. I en konstruktion som enbart använder UID visar ett godkänt matchande identifierarvärde inte att någon innehar en kryptografisk hemlighet. En krets med säkerhetsfunktioner ger värde först när installerad läsare och applikation använder funktionerna.

När kryptografisk kortautentisering krävs ska ni dokumentera stödd applikation, nyckelägarskap, provisioneringsprocess, ersättningsrutiner och migrationsansvar. Förvara inga hemligheter i UID-överlämningsfiler. NIST:s RFID-säkerhetsvägledning, avsnitt 5.3.1, beskriver skillnaden mellan identifierare och autentiseringskontroller. Det är en grundläggande vägledning publicerad 2007; använd aktuell produktdokumentation för att välja algoritmer och mekanismer för nyckelhantering som stöds.

Säkra anslutningen mellan station och backend separat. OCA:s aktuella Security Operations Guide, avsnitt 4.2 och 4.4, beskriver Security Profile 2 som TLS med Basic Authentication och Profile 3 som TLS med klientcertifikat och behandlar lagring av autentiseringsuppgifter. Bekräfta installerad transportprofil, certifikatvalidering och hantering av stationens autentiseringsuppgifter. Inställningarna skyddar en annan anslutning än länken mellan kort och läsare.

7. Lägg till roamingauktorisering när tjänsten kräver det

En privat arbetsplatsinstallation kan klara sig med den egna plattformens register. Roaming tillför ytterligare en gräns: laddoperatören, CPO, måste inhämta auktorisering från relevant leverantör av e-mobilitetstjänster, eMSP, via den integration och det kommersiella upplägg som stöds.

I OCPI 2.3.0 innehåller en tokenpost ägarleverantörens lands- och partsidentifierare samt tokenens UID, typ, giltighet och policy för tillåtelselista. Policyn ALLOWED_OFFLINE gäller kommunikation mellan CPO och eMSP. Att en laddare tappar anslutningen till CSMS är ett separat avbrott. Testa båda gränserna om båda finns.

Tokens-modulen skiljer också mellan en giltig token och en som är tillåten på en viss plats. Ogiltigförklaring sprids genom en uppdaterad token med valid: false; mekanismen är inte att radera token via det gränssnittet. Kontrollera den officiella Tokens-modulen i OCPI 2.3.0 mot den version ni avtalat med partnern.

Ange utfärdare och deltagande nätverk i piloten, fastställ förväntad auktoriseringsväg och kontrollera den resulterande sessionen och laddningsposten. Samma fysiska kort i flera tjänster kräver fortfarande rätt registrering, behörigheter och avtal.

8. Driftsätt hela åtkomstlivscykeln

Använd en testmatris med förväntade resultat nedskrivna före testet. Kör den för varje unik konfiguration av hårdvara, firmware och backend och gör sedan stickprov i den installerade utrustningen mot godkänd konfiguration.

Spara tid, stations- och uttagsidentifierare, firmware, testkortsreferens, gällande konfiguration, förväntat och faktiskt resultat samt relevant transaktionspost för varje körning. Maskera personuppgifter i underlag som delas utanför driftteamet.

När ett kort försvinner ska ni registrera när anmälan kom och när varje anslutet system kvitterade ändringen. En frånkopplad station kan inte ta emot en ny spärrning omedelbart. Den faktiska exponeringen beror på lagrat auktoriseringstillstånd, giltighetsregler och beteende vid återanslutning. Hantera det intervallet i driftrutinen.

Felsök en misslyckad blippning vid rätt gräns

Samla in ett misslyckat försök med tidsstämpel och kortreferens och gå sedan igenom underlaget. Kontrollerna avgränsar undersökningen utan att förutsätta att varje avslag har samma orsak.

Exempel på införande vid en fordonsdepå

Tänk er en fiktiv depå med 60 förare, 12 laddpunkter och två laddarmodeller. Operatören vill hänföra åtkomsten till enskilda förare, begränsa den till depån och låta godkända förare ladda även vid backendavbrott.

Börja med fem provkort eller provbrickor. Fånga den rapporterade identifieraren på varje laddarmodell och kom överens om mappningen till leverantörsfilen. Registrera proven på ett pilotkonto, tilldela depååtkomst och bekräfta avsett kostnadsställe.

Om utrustningen stöder en hanterad lokal lista förinläser ni pilotens identifieringsmedier och dokumenterar kvitterad version. Håll okända identifieringsmedier offline avaktiverade för den föreslagna policyn. Koppla bort stationen från CSMS i ett kontrollerat test. Prova sedan ett förinläst kort, ett okänt kort och ett spärrat kort med ett avsiktligt dokumenterat inaktuellt lokalt tillstånd. Återställ anslutningen och verifiera uppdaterings- och transaktionsposterna.

Slutför tester av avslag online, sessionsstopp och debitering på båda modellerna. När piloten har godkänts stämmer ni av produktionsfilen med 60 kort mot backendregistret, löser avvikelser och delar ut korten med en enkel rutin för förlustanmälan. Upprepa relevanta acceptanstester efter väsentliga ändringar av firmware, läsarläge eller plattform.

Frågor att lösa före beställning

Måste RFID-laddkort programmeras?

För en lösning som läser kortets befintliga UID kan konfigurationen bestå av att registrera värdet och tilldela åtkomst i plattformen. En lösning med skyddad applikation kan kräva kortpersonalisering och samordnad läsarkonfiguration. Specificera det exakta läsarflödet innan någon av tjänsterna beställs.

Kan ett befintligt personalkort även ge tillgång till laddaren?

Det kan vara möjligt om läsaren stöder korttekniken, den nödvändiga identifieraren är tillgänglig och stabil och plattformen tillåter registrering. Inhämta godkännande från kortsystemets ägare och testa faktiska prov. Som exempel på plattformsspecifik registrering beskriver Easees dokumentation om konto och lokala nycklar olika registreringsomfattningar och varnar för föränderliga identifierare.

Fungerar ett kort i alla laddnätverk?

Fastställ varje avsett nätverk separat. Fysisk läsbarhet, registrering, kontobehörigheter och eventuellt roamingavtal ingår alla i acceptanskriterierna. Testa det deltagande nätverket i stället för att anta täckning utifrån kortets utseende.

Vad ska kortleverantören få?

Ange läsarkrav, godkänd mappning av providentifierare, synligt numreringssystem, material- och tryckspecifikation, antal och överenskommet format för dataleverans. Ange ansvarig för backendimport och provgodkännande. Överför applikationshemligheter genom en separat överenskommen säker provisioneringsprocess när lösningen kräver det.

Förbered en provspecifikation för installationen

Samla laddarmodell och firmware, backendnamn och protokollversion, nödvändigt identifieringsläge, bekräftad identifierarrepresentation och avsedd offlinepolicy i en specifikation. Använd ChargeRFID:s identifieringslabb för att granska dataöverlämningen och beställ färdiga prov till piloten. Godkänn det fysiska identifieringsmediet och hela åtkomstflödet tillsammans innan produktionsbeställningen frisläpps.