Forside/Alle produkter/RFID-kort til OCPP-ladenetværk
RFID-kort til OCPP-ladenetværk — produktvisning 1
01 / 04

Adgangsmiddel til elbilopladning

Fremstillet efter specifikation

RFID-kort til OCPP-ladenetværk

RFID-identifikationsmidler forberedt til det identifikator- og autorisationsworkflow, der bruges mellem læsere i ladestandere og OCPP-baserede administrationssystemer for opladning.

OCPP-workflowsidTag / idTokenUID-formatering
Materiale
Genanvendt PVC, træbaseret eller godkendt alternativ kortkrop
Størrelse
CR80 / ISO ID-1 nominelt format (85.60 × 53.98 mm)
MOQ
Fra 500 stk., afhængigt af materiale og chip
Leveringstid
Bekræftes efter godkendelse af tokenformat, design og prøve

Kompatibilitet bekræftes i forhold til din læser og dit token-workflow. MOQ og tidsplan afhænger af det godkendte materiale, chip, personalisering og finish.

01Match mellem læser og chip
02Identifikatorformat
03Godkendelse af færdig prøve
04Overdragelse af batchdata

Produktoversigt / 01

Hvad et ‘OCPP RFID-kort’ faktisk gør

Et RFID-kort kører ikke OCPP. Det præsenterer en identifikator for ladestanderens kontaktløse læser. Ladestanderens software bruger derefter OCPP til at sende identifikatoren til ladestanderens administrationssystem (CSMS), som accepterer, blokerer eller på anden vis vurderer ladetokenet.

I OCPP 1.6 håndteres denne identifikator typisk som et idTag; OCPP 2.0.1 bruger den bredere idToken-model. Et vellykket kortprogram har derfor to kompatibilitetslag: Den fysiske læser skal genkende chippen, og identifikatorens repræsentation skal svare til det, som ladestanderen og CSMS forventer.

01

OCPP er en systemprotokol

Bekræft implementeringen i ladestanderen og CSMS separat; selve det fysiske kort er ikke OCPP-certificeret.

02

Læserteknologi

Identificér frekvens, ISO-protokol, understøttede chips og eventuelle begrænsninger i firmwaren til ladestanderens læser.

03

Tokenrepræsentation

Dokumentér UID-længde, byterækkefølge, hexadecimalt eller decimalt format, store/små bogstaver, udfyldning og eventuelle præfiksregler.

04

Online- og offlineadfærd

Definér, hvordan nye, blokerede og erstatningstokens når frem til lokale autorisationslister eller cachelagrede data i ladestanderen.

Funktioner og muligheder / 02

Hvad der kan specificeres.

Vi fremstiller det fysiske RFID-adgangsmiddel og klargør dets identifikatordata til arbejdsgangen i operatørens ladeplatform.

01

RFID-inlay matchet til læseren

Kombinationer af chip og antenne vælges ud fra læserprotokollen i ladestanderen og den fysiske præsentation.

02

Arbejdsgange med UID på 4 eller 7 byte

Identifikatorens længde kan planlægges ud fra den valgte chipfamilie og begrænsningerne i det installerede system.

03

Hexadecimal eller decimal eksport

Leveringsdata kan bruge præcis den repræsentation, der er aftalt til CSMS-import, herunder byterækkefølge og formateringsregler.

04

Synlig tokenreference

Et påtrykt kortnummer kan holdes adskilt fra den elektroniske identifikator og samtidig forblive koblet i mappingfilen.

05

Programdesign og materialer

Kortkroppe af genanvendt PVC, træbaserede materialer og andre materialer kan bruge samme godkendte elektroniske specifikation.

06

Data til erstatning og genbestilling

Kontrollerede nummerserier og batchfiler understøtter nye udstedelser uden at duplikere aktive identifikationsmidler.

Teknisk egnethed / 03

Fire lag skal stemme overens før udrulning

De fleste fejl i drift skyldes en antagelse i grænsefladen mellem chip, læser, ladestanderens software og administrationssystemet.

01

Kort til læser

Læseren skal understøtte kortets frekvens og protokol og levere tilstrækkelig RF-ydeevne i den installerede position.

02

Læser til ladestanderens software

Firmwaren afgør, hvilke bytes der indlæses, og hvordan identifikatoren normaliseres før en autorisationsanmodning.

03

Ladestander til CSMS

OCPP-implementeringen overfører tokenet inden for det understøttede autorisations- og transaktionsflow.

04

CSMS til konto

Det importerede token skal knyttes til den rette kontrakt, fører, køretøj eller tarif og følge reglerne for aktivering og spærring.

05

Sikkerhedsmodel

Hvis autorisationen kun bruger et offentligt UID, skaber en AES-kompatibel chip ikke i sig selv gensidig autentificering; læser- og backenddesignet skal udnytte den.

Fuld specifikation / 04

Adskil det fysiske kort fra dets adgangsdata.

Værdierne nedenfor angiver den tilgængelige produktvariant og erstatter ikke validering med læseren. Det endelige tilbud dokumenterer den præcise konstruktion, den elektroniske konfiguration og de data, der skal leveres.

Anmod om prøver

Fysisk

Materiale
Genanvendt PVC, træbaseret eller godkendt alternativ kortkrop
Størrelse
CR80 / ISO ID-1 nominelt format (85.60 × 53.98 mm)

Teknisk

Frekvens
Typisk 13.56 MHz / ISO 14443A; bekræftes med ladestanderens læser
Læseafstand
Afhænger af læser og installeret antenne; verificeres på færdige prøver
Sikkerhed
Ren UID eller sikker applikation afhængigt af ladestanderlæserens kapacitet

Bestilling

MOQ
Fra 500 stk., afhængigt af materiale og chip
Leveringstid
Bekræftes efter godkendelse af tokenformat, design og prøve
Support
Gennemgang af identifikatorformat, mappingfil og planlægning af testbatch

Produktionsforløb / 05

Godkend hele workflowet før volumenproduktion.

Prøven skal dokumentere konstruktion, tryk, elektronisk funktion og datahåndtering samlet. Den godkendte reference styrer derefter produktion og genbestillinger.

  1. 01

    Teknisk brief

    Læser, nuværende adgangsmiddel, platform, mængde og driftsmiljø

  2. 02

    Produktionsprøve

    Foreslået materiale, inlay, grafik, kodning og variable data

  3. 03

    Systemvalidering

    Fysisk læsning, præcis registrering af token, dataimport og live-autorisation

  4. 04

    Produktion og QA

    Godkendte mastere, kontrollerede data, batchkontroller og gennemgang af pakning

  5. 05

    Levering og genbestillinger

    Endelig mappingfil, forsendelsesregistrering og opbevaret reference til genbestilling

Ofte stillede spørgsmål / 06

Spørgsmål, som indkøbere stiller før bestilling.

Svarene er baseret på det fysiske adgangsmiddel og produktionsomfanget. Din ladeplatform er fortsat ansvarlig for regler om konti, takster og autorisation.

01

Er RFID-kort i sig selv OCPP-kompatible?

Nej. OCPP gælder for kommunikationen mellem ladestandere og administrationssystemer. RFID-kortet præsenterer en identifikator for standerens læser; standeren overfører derefter det resulterende token gennem sit OCPP-autorisationsflow.

02

Hvad er forskellen på idTag og idToken?

idTag er den identifikatorbetegnelse, der bruges i autorisations- og transaktionsmeddelelser i OCPP 1.6. OCPP 2.0.1 bruger idToken som et bredere tokenobjekt, der kan repræsentere RFID og andre autorisationsmetoder.

03

Hvorfor har UID-format og byterækkefølge betydning?

Det samme fysiske UID kan repræsenteres i forskellige byterækkefølger og som hexadecimal eller decimal tekst. Hvis ladestanderen eksporterer én repræsentation, mens CSMS-databasen gemmer en anden, bliver et gyldigt kort afvist.

04

Kan ét RFID-kort fungere på alle OCPP-ladestandere?

Ikke automatisk. OCPP-understøttelse garanterer ikke, at alle ladestandere har samme RFID-læser, chipunderstøttelse eller håndtering af identifikatorer. Definér den relevante bestand af ladestandere, og validér prøver på repræsentativ hardware.

05

Gør et AES-autentificeret 13.56 MHz-identifikationsmiddel OCPP-autorisation sikker?

Et AES-autentificeret 13.56 MHz-identifikationsmiddel understøtter kryptografiske applikationer, men sikkerhedsgevinsten opnås kun, hvis ladestanderens læser og programmet er konfigureret til at autentificere den pågældende applikation. Mange ladesystemer læser et offentligt UID, selv fra en chip, der understøtter sikre applikationer.

06

Hvad skal en OCPP-korttest omfatte?

Test fysisk læsning, den præcise tokenværdi i ladestanderen, OCPP-autorisation via CSMS, lokal eller offline adfærd, hvor det anvendes, kontokobling, spærring og erstatning.

Inkluderet i hver ordre

Hver ordre leveres med en datakontrakt og en acceptpakke.

Før produktionen starter, fastlægger vi identifikatorformatet sammen med jeres backend-team: bytelængde, repræsentation, byterækkefølge og politik for foranstillede nuller. Ordren leveres derefter med en maskinlæsbar datakontrakt og acceptvektorer, som jeres udviklere kan teste mod, før det første kort ankommer.

Se, hvordan acceptpakken fungerer
01JSON-datakontrakt aftalt før produktion
02Acceptvektorer til verifikation i backend
03Personaliseringsfil i præcis det format, jeres backend bruger