Hjem/Alle produkter/RFID-kort for OCPP-ladenettverk
RFID-kort for OCPP-ladenettverk — produktvisning 1
01 / 04

Ladekort og ladebrikker for elbil

Laget etter spesifikasjon

RFID-kort for OCPP-ladenettverk

RFID-identifikatorer forberedt for identifikator- og autorisasjonsflyten som brukes mellom lesere i elbilladere og OCPP-baserte ladeadministrasjonssystemer.

OCPP-arbeidsflyteridTag / idTokenUID-formatering
Materiale
Resirkulert PVC, trebasert eller godkjent alternativ kortkropp
Størrelse
Nominelt CR80 / ISO ID-1-format (85.60 × 53.98 mm)
MOQ
Fra 500 stk., avhengig av materiale og chip
Leveringstid
Bekreftes etter godkjenning av tokenformat, design og prøve

Kompatibilitet bekreftes opp mot din leser og token-arbeidsflyt. MOQ og tidsbruk avhenger av godkjent materiale, chip, personalisering og finish.

01Samsvar mellom leser og brikke
02Identifikatorformat
03Godkjenning av ferdig prøve
04Overlevering av batchdata

Produktoversikt / 01

Hva et «OCPP RFID-kort» faktisk gjør

Et RFID-kort kjører ikke OCPP. Det presenterer en identifikator for ladestasjonens kontaktløse leser. Ladestasjonens programvare bruker deretter OCPP til å sende identifikatoren til administrasjonssystemet for ladestasjoner (CSMS), som godtar, sperrer eller på annen måte vurderer ladetokenet.

I OCPP 1.6 håndteres denne identifikatoren vanligvis som en idTag; OCPP 2.0.1 bruker den bredere idToken-modellen. Et vellykket kortprogram har derfor to kompatibilitetsnivåer: den fysiske leseren må gjenkjenne brikken, og representasjonen av identifikatoren må samsvare med det laderen og CSMS forventer.

01

OCPP er en systemprotokoll

Bekreft implementeringen i ladestasjonen og CSMS hver for seg; selve det fysiske kortet er ikke OCPP-sertifisert.

02

Leserteknologi

Identifiser frekvens, ISO-protokoll, støttede brikker og eventuelle begrensninger i fastvaren til laderens leser.

03

Representasjon av token

Dokumenter UID-lengde, byte-rekkefølge, heksadesimalt eller desimalt format, store/små bokstaver, utfylling og eventuelle prefiksregler.

04

Online- og offline-atferd

Definer hvordan nye, sperrede og erstattede tokens når frem til lokale autoriseringslister eller hurtigbufrede stasjonsdata.

Funksjoner og alternativer / 02

Hva som kan spesifiseres.

Vi produserer selve RFID-kortet eller ladebrikken og klargjør identifikatordataene for operatørens arbeidsflyt i ladeplattformen.

01

Lesertilpasset RFID-inlay

Kombinasjoner av brikke og antenne velges ut fra protokollen til laderens leser og den fysiske presentasjonen.

02

Arbeidsflyter for UID på 4 eller 7 byte

Lengden på identifikatoren kan planlegges ut fra valgt chipfamilie og begrensningene i det installerte systemet.

03

Eksport i heksadesimalt eller desimalt format

Leveransedata kan bruke nøyaktig den representasjonen som er avtalt for CSMS-import, inkludert byterekkefølge og formateringsregler.

04

Synlig tokenreferanse

Et trykt kortnummer kan holdes adskilt fra den elektroniske identifikatoren og samtidig være koblet til den i tilordningsfilen.

05

Programmets design og materialer

Kortkropper av resirkulert PVC, trebaserte materialer og andre materialer kan bruke samme godkjente elektroniske spesifikasjon.

06

Data for erstatning og etterbestilling

Kontrollerte nummerserier og batchfiler gjør det mulig å utstede nye kort uten å duplisere aktive identifikatorer.

Teknisk tilpasning / 03

Fire lag må stemme overens før utrulling

De fleste feil i drift skyldes en antakelse i grenseflaten mellom chip, leser, laderprogramvare og administrasjonssystem.

01

Kort til leser

Leseren må støtte kortets frekvens og protokoll og gi tilstrekkelig RF-ytelse i den installerte posisjonen.

02

Leser til laderprogramvare

Fastvaren bestemmer hvilke byte som registreres, og hvordan identifikatoren normaliseres før en autorisasjonsforespørsel.

03

Lader til CSMS

OCPP-implementasjonen overfører tokenet innenfor den støttede autorisasjons- og transaksjonsflyten.

04

CSMS til konto

Det importerte tokenet må tilordnes riktig kontrakt, sjåfør, kjøretøy eller tariff og følge reglene for aktivering og sperring.

05

Sikkerhetsmodell

Hvis autorisasjonen bare bruker en offentlig UID, gir ikke en AES-kompatibel chip i seg selv gjensidig autentisering; leseren og backend-løsningen må være utformet for å bruke den.

Full spesifikasjon / 04

Skill det fysiske kortet fra identifikasjonsdataene på det.

Verdiene nedenfor viser tilgjengelig produktløp og erstatter ikke validering mot leser. Det endelige tilbudet angir nøyaktig konstruksjon, elektronisk konfigurasjon og dataleveranser.

Be om prøver

Fysisk

Materiale
Resirkulert PVC, trebasert eller godkjent alternativ kortkropp
Størrelse
Nominelt CR80 / ISO ID-1-format (85.60 × 53.98 mm)

Teknisk

Frekvens
Vanligvis 13.56 MHz / ISO 14443A; bekreftes med laderens leser
Leseavstand
Avhenger av leser og installert antenne; verifiseres på ferdige prøver
Sikkerhet
Kun UID eller sikker applikasjon i henhold til laderleserens funksjonalitet

Bestilling

MOQ
Fra 500 stk., avhengig av materiale og chip
Leveringstid
Bekreftes etter godkjenning av tokenformat, design og prøve
Støtte
Gjennomgang av identifikatorformat, tilordningsfil og planlegging av testbatch

Produksjonsløp / 05

Godkjenn hele arbeidsflyten før volumproduksjon.

Prøven skal dokumentere konstruksjon, trykk, elektronisk oppførsel og datahåndtering samlet. Den godkjente referansen styrer deretter produksjon og etterbestillinger.

  1. 01

    Teknisk underlag

    Leser, nåværende ladekort eller ladebrikke, plattform, antall og driftsmiljø

  2. 02

    Produksjonsprøve

    Foreslått materiale, inlay, design, koding og variable data

  3. 03

    Systemvalidering

    Fysisk lesing, nøyaktig registrering av token, dataimport og live autorisasjon

  4. 04

    Produksjon og QA

    Godkjente mastere, kontrollerte data, batchkontroller og pakkegjennomgang

  5. 05

    Levering og etterbestillinger

    Endelig mappingfil, forsendelsesregister og oppbevart referanse for etterbestilling

Ofte stilte spørsmål / 06

Spørsmål kjøpere stiller før bestilling.

Svarene er basert på det fysiske ladekortet eller ladebrikken og produksjonsomfanget. Ladeplattformen din er fortsatt ansvarlig for regler for konto, tariff og autorisasjon.

01

Er RFID-kort i seg selv OCPP-kompatible?

Nei. OCPP gjelder kommunikasjonen mellom ladestasjoner og administrasjonssystemer. RFID-kortet presenterer en identifikator for stasjonens leser; stasjonen overfører deretter det resulterende tokenet gjennom sin OCPP-autorisasjonsflyt.

02

Hva er forskjellen mellom idTag og idToken?

idTag er identifikatorbegrepet som brukes i autorisasjons- og transaksjonsmeldinger i OCPP 1.6. OCPP 2.0.1 bruker idToken som et bredere tokenobjekt som kan representere RFID og andre autorisasjonsmetoder.

03

Hvorfor er UID-format og byterekkefølge viktig?

Den samme fysiske UID-en kan representeres i ulike byterekkefølger og som heksadesimal eller desimal tekst. Hvis laderen eksporterer én representasjon mens CSMS-databasen lagrer en annen, vil et gyldig kort bli avvist.

04

Kan ett RFID-kort fungere på alle OCPP-ladere?

Ikke automatisk. OCPP-støtte garanterer ikke at alle ladere har samme RFID-leser, chipstøtte eller identifikatorhåndtering. Definer målparken av ladere og valider prøver på representativ maskinvare.

05

Gjør en AES-autentisert 13.56 MHz-identifikator OCPP-autorisasjonen sikker?

En AES-autentisert 13.56 MHz-identifikator støtter kryptografiske applikasjoner, men sikkerhetsgevinsten oppnås bare hvis laderens leser og programmet er konfigurert til å autentisere denne applikasjonen. Mange ladesystemer leser en offentlig UID selv fra en chip med sikkerhetsfunksjoner.

06

Hva bør inngå i en OCPP-korttest?

Test fysisk lesing, nøyaktig tokenverdi i laderen, OCPP-autorisasjon gjennom CSMS, lokal eller frakoblet atferd der dette brukes, kontotilordning, sperring og erstatning.

Inkludert i hver bestilling

Hver bestilling leveres med en datakontrakt og en akseptansepakke.

Før produksjonen starter, fastsetter vi identifikatorformatet sammen med backend-teamet deres: bytelengde, representasjon, byte-rekkefølge og håndtering av innledende nuller. Bestillingen leveres deretter med en maskinlesbar datakontrakt og akseptansevektorer som utviklerne deres kan teste mot før det første kortet ankommer.

Se hvordan akseptansepakken fungerer
01JSON-datakontrakt avtalt før produksjon
02Akseptansevektorer for verifisering i backend
03Personaliseringsfil i nøyaktig det formatet backend-systemet deres bruker