Hem/Alla produkter/RFID-kort för OCPP-laddnätverk
RFID-kort för OCPP-laddnätverk — produktvy 1
01 / 04

Identifieringsmedium för laddning av elfordon

Tillverkat enligt specifikation

RFID-kort för OCPP-laddnätverk

RFID-identifierare förberedda för det identifierar- och auktoriseringsflöde som används mellan laddarens läsare och OCPP-baserade administrationssystem för laddning.

OCPP-arbetsflödenidTag / idTokenUID-formatering
Material
Kortkropp i återvunnen PVC, trä eller godkänt alternativ
Storlek
Nominellt CR80 / ISO ID-1-format (85.60 × 53.98 mm)
MOQ
Från 500 st, beroende på material och chip
Leveranstid
Bekräftas efter godkännande av tokenformat, grafik och prov

Kompatibiliteten bekräftas mot din läsare och ditt tokenflöde. MOQ och tidsplan beror på godkänt material, chip, personalisering och finish.

01Matchning mellan läsare och chip
02Identifierarformat
03Godkännande av färdigt prov
04Överlämning av batchdata

Produktöversikt / 01

Vad ett ”OCPP RFID-kort” faktiskt gör

Ett RFID-kort kör inte OCPP. Det visar upp en identifierare för laddstationens kontaktlösa läsare. Laddstationens programvara använder sedan OCPP för att skicka identifieraren till laddstationens ledningssystem (CSMS), som godkänner, spärrar eller på annat sätt utvärderar laddtoken.

I OCPP 1.6 hanteras identifieraren vanligtvis som en idTag; OCPP 2.0.1 använder den bredare idToken-modellen. Ett lyckat kortprogram har därför två kompatibilitetsnivåer: den fysiska läsaren måste känna igen chipet, och identifierarens representation måste motsvara det som laddaren och CSMS förväntar sig.

01

OCPP är ett systemprotokoll

Bekräfta laddstationens och CSMS-systemets implementering separat; själva det fysiska kortet är inte OCPP-certifierat.

02

Läsarteknik

Identifiera frekvens, ISO-protokoll, chip som stöds och eventuella begränsningar i laddarläsarens firmware.

03

Tokenrepresentation

Dokumentera UID-längd, byteordning, hexadecimalt eller decimalt format, versaler/gemener, utfyllnad och eventuella prefixregler.

04

Beteende online och offline

Definiera hur nya, spärrade och ersättande token når lokala auktoriseringslistor eller cachad stationsdata.

Funktioner och alternativ / 02

Vad som kan specificeras.

Vi tillverkar det fysiska RFID-identifieringsmedlet och förbereder dess identifierardata för operatörens arbetsflöde i laddplattformen.

01

RFID-inlägg matchat mot läsaren

Kombinationer av chip och antenn väljs utifrån målladdarens läsarprotokoll och hur kortet fysiskt hålls mot läsaren.

02

Arbetsflöden för UID på 4 eller 7 byte

Identifierarens längd kan planeras utifrån vald chipfamilj och begränsningarna i det installerade systemet.

03

Export i hexadecimalt eller decimalt format

Leveransdata kan använda exakt den representation som avtalats för import till CSMS, inklusive byteordning och formateringsregler.

04

Synlig tokenreferens

Ett tryckt kortnummer kan hållas åtskilt från den elektroniska identifieraren och samtidigt vara kopplat till den i mappningsfilen.

05

Programmets grafik och material

Kortkroppar i återvunnen PVC, träbaserade material och andra material kan använda samma godkända elektroniska specifikation.

06

Data för ersättning och efterbeställning

Kontrollerade nummerserier och batchfiler gör det möjligt att utfärda nya kort utan att aktiva identifierare dupliceras.

Teknisk lämplighet / 03

Fyra lager måste stämma överens före utrullning

De flesta fel i drift beror på ett antagande i gränssnittet mellan chip, läsare, laddarens programvara och administrationssystem.

01

Kort till läsare

Läsaren måste stödja kortets frekvens och protokoll och ge tillräcklig RF-prestanda i den monterade positionen.

02

Läsare till laddarens programvara

Den fasta programvaran avgör vilka byte som registreras och hur identifieraren normaliseras före en auktoriseringsbegäran.

03

Laddare till CSMS

OCPP-implementeringen överför token inom det auktoriserings- och transaktionsflöde som stöds.

04

CSMS till konto

Den importerade token måste kopplas till rätt avtal, förare, fordon eller tariff och följa reglerna för aktivering och spärrning.

05

Säkerhetsmodell

Om auktoriseringen endast använder ett publikt UID skapar ett AES-kapabelt chip inte i sig ömsesidig autentisering; läsarens och backendsystemets utformning måste utnyttja den.

Fullständig specifikation / 04

Skilj det fysiska kortet från dess identifieringsdata.

Värdena nedan visar tillgänglig produktväg och ersätter inte validering mot läsaren. Den slutliga offerten dokumenterar exakt konstruktion, elektronisk konfiguration och dataleveranser.

Begär prover

Fysiskt

Material
Kortkropp i återvunnen PVC, trä eller godkänt alternativ
Storlek
Nominellt CR80 / ISO ID-1-format (85.60 × 53.98 mm)

Tekniskt

Frekvens
Normalt 13.56 MHz / ISO 14443A; bekräfta med laddarens läsare
Läsavstånd
Beror på läsare och installerad antenn; verifiera på färdiga prover
Säkerhet
Enbart UID eller säker applikation beroende på laddarläsarens kapacitet

Beställning

MOQ
Från 500 st, beroende på material och chip
Leveranstid
Bekräftas efter godkännande av tokenformat, grafik och prov
Support
Granskning av identifierarformat, mappningsfil och planering av testbatch

Produktionsväg / 05

Godkänn hela arbetsflödet före volymproduktion.

Provet ska verifiera konstruktion, tryck, elektroniskt beteende och datahantering samtidigt. Den godkända referensen styr sedan produktion och ombeställningar.

  1. 01

    Teknisk kravspecifikation

    Läsare, nuvarande identifieringsmedium, plattform, kvantitet och driftmiljö

  2. 02

    Produktionsprov

    Föreslaget material, inlay, tryckoriginal, kodning och variabel data

  3. 03

    Systemvalidering

    Fysisk avläsning, exakt registrering av token, dataimport och auktorisering i drift

  4. 04

    Produktion och kvalitetssäkring

    Godkända mallar, kontrollerad data, batchkontroller och granskning av packning

  5. 05

    Leverans och ombeställningar

    Slutlig mappningsfil, leveransregistrering och sparad referens för ombeställning

Vanliga frågor / 06

Frågor som köpare ställer före beställning.

Svaren utgår från det fysiska identifieringsmediet och produktionsomfattningen. Din laddplattform ansvarar fortsatt för regler kring konton, tariffer och auktorisering.

01

Är RFID-korten i sig OCPP-kompatibla?

Nej. OCPP gäller kommunikationen mellan laddstationer och administrationssystem. RFID-kortet presenterar en identifierare för stationens läsare; stationen överför sedan den resulterande token genom sitt OCPP-auktoriseringsflöde.

02

Vad är skillnaden mellan idTag och idToken?

idTag är identifierarbegreppet som används i auktoriserings- och transaktionsmeddelanden i OCPP 1.6. OCPP 2.0.1 använder idToken som ett bredare tokenobjekt som kan representera RFID och andra auktoriseringsmetoder.

03

Varför spelar UID-format och byteordning roll?

Samma fysiska UID kan representeras i olika byteordningar och som hexadecimal eller decimal text. Om laddaren exporterar en representation medan CSMS-databasen lagrar en annan avvisas ett giltigt kort.

04

Kan ett RFID-kort fungera med alla OCPP-laddare?

Inte automatiskt. OCPP-stöd garanterar inte att alla laddare har samma RFID-läsare, chipstöd eller hantering av identifierare. Definiera den aktuella laddparken och validera prover på representativ hårdvara.

05

Gör en AES-autentiserad 13.56 MHz-identifierare OCPP-auktoriseringen säker?

En AES-autentiserad 13.56 MHz-identifierare stöder kryptografiska applikationer, men säkerhetsvinsten uppstår endast om laddarens läsare och programmet är konfigurerade för att autentisera den applikationen. Många laddsystem läser ett publikt UID även från ett chip med säkerhetsfunktioner.

06

Vad bör ingå i ett OCPP-korttest?

Testa fysisk läsning, exakt tokenvärde i laddaren, OCPP-auktorisering via CSMS, lokalt beteende eller offlinebeteende där det används, kontomappning, spärrning och ersättning.

Ingår i varje order

Varje order levereras med ett datakontrakt och ett acceptanspaket.

Innan produktionen startar fastställer vi identifierarformatet tillsammans med ert backend-team: bytelängd, representation, byteordning och policy för inledande nollor. Ordern levereras sedan med ett maskinläsbart datakontrakt och acceptansvektorer som era utvecklare kan testa mot innan det första kortet anländer.

Se hur acceptanspaketet fungerar
01JSON-datakontrakt överenskommet före produktion
02Acceptansvektorer för verifiering i backend
03Personaliseringsfil i exakt det format som er backend använder