Hem/Alla produkter/Laddkort för elfordonsflottor
Laddkort för elfordonsflottor — produktvy 1
01 / 04

Identifieringsmedium för laddning av elfordon

Tillverkat enligt specifikation

Laddkort för elfordonsflottor

Varumärkta RFID-laddidentifierare för fordonsflottor med unika tokendata, numrering per förare eller fordon, bulkimport till plattform och kontrollerad påfyllning.

FlottdriftTokendata i bulkPåfyllning
Material
Återvunnen PVC, standard-PVC 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 dataformat, 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

Fysiska identifierare för administrerade elbilsflottor

Ett laddkort för elbilsflottor är en fysisk token som utfärdas till en förare, ett fordon, en depå eller ett kostnadsställe så att laddsessioner kan tilldelas och styras av en flott- eller e-mobilitetsplattform. Kortet identifierar kontot; sessionsposter, priser, begränsningar och rapportering hanteras normalt i backendsystemet i stället för att lagras på kortet.

Ett flottkort kan användas i operatörens egen laddpark eller i ett roamingprogram. Roaming skapas genom kommersiella och tekniska relationer mellan eMSP:er, CPO:er och hubbar – inte genom att trycka en logotyp eller välja en viss kortkropp. Identifierardata måste registreras och dirigeras via den plattform som hanterar dessa relationer.

01

Tilldelningsmodell

Bestäm om varje token tillhör en förare, ett fordon, en pool, en depå eller ett kostnadsställe och hur överföringar registreras.

02

Nätverksomfattning

Förteckna depå-, arbetsplats-, publika och roamingmiljöer och identifiera vilken plattform som ansvarar för auktoriseringen.

03

Livscykelkontroller

Definiera rutiner för utfärdande, aktivering, avstängning, förlust, ersättning, utgång och återlämning innan korten distribueras.

04

Avstämningsfält

Samordna synliga kortnummer, tokenposter och referenser i flottsystemet så att avvikelser snabbt kan spåras.

Funktioner och alternativ / 02

Vad som kan specificeras.

Det fysiska kortet kan utformas för att minska supportarbetet och integreras smidigt med introduktion och påfyllning i fordonsflottan.

01

Numrering per förare eller fordon

Synliga referenser kan följa operatörens tilldelningsmodell utan att det elektroniska UID:t exponeras som supportidentifierare.

02

Tokendata i bulk

Strukturerade leveransfiler stöder import, tilldelning och aktivering i flott- eller e-mobilitetsplattformen.

03

Anpassad programgrafik

Varumärke, supportinstruktioner, nödinformation och obligatorisk juridisk text kan disponeras på kortet.

04

Slitstarka kortmaterial

Återvunnen PVC och alternativa kortkroppar kan väljas utifrån hur korten hanteras i plånbok, fordon och depå.

05

Alternativ med kort och nyckelbrickor

Blandade formfaktorer kan användas för olika förargrupper och ändå följa ett kontrollerat arbetsflöde för tokendata.

06

Schemalagd påfyllning

Nummerserier, originalgrafik och packningsregler kan sparas för ersättnings- och tillväxtbatcher.

Teknisk lämplighet / 03

Kortet är ett lager i styrningen av flottans laddning

Användbar rapportering och roaming beror på systemen runt identifieraren. Kortet måste ge dessa system en stabil, spårbar token.

01

Tilldelningen finns i plattformen

Rapportering per förare, per fordon och per kostnadsställe bygger på att kortets token mappas till rätt post i flottsystemet.

02

Roaming kräver registrering i plattformen

Ett tillverkat kort fungerar i flera nätverk först när dess token har registrerats och godkänts via relevant eMSP-, CPO- eller roamingrelation.

03

Ersättning måste skapa en ny identifierare

Förlorade kort ska spärras och ersättas med en ny unik token; att trycka om samma synliga nummer kräver inte att det elektroniska UID:t återanvänds.

04

Offlineauktorisering kräver styrning

Där laddare använder lokala tokenlistor ska tidpunkter för synkronisering definieras, liksom vad som ska ske efter att ett kort har spärrats.

05

Dataformat bör testas i batchskala

Validera rubriker, avgränsare, inledande nollor och identifierarens representation innan produktionsfilen importeras.

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
Återvunnen PVC, standard-PVC 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 flottans läsarpark
Läsavstånd
Beror på läsare och installerad antenn; provvalidering krävs
Säkerhet
Enbart UID eller säker applikation beroende på plattformens och läsarens utformning

Beställning

MOQ
Från 500 st, beroende på material och chip
Leveranstid
Bekräftas efter godkännande av dataformat, grafik och prov

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

Vilken information lagras på ett laddkort för fordonsflottor?

Många program använder endast en chipidentifierare som token. Förarinformation, fordonsdata, tariffer och sessionshistorik finns kvar i backendsystemet. Säkra applikationer kan lagra ytterligare data när läsaren och systemet är utformade för att använda dem.

02

Kan ett flottkort fungera i flera laddnätverk?

Ja, när flottans e-mobilitetsleverantör eller plattform har de roamingrelationer eller bilaterala nätverksrelationer som krävs och registrerar token korrekt. Det fysiska kortet i sig skapar inte åtkomst till nätverk.

03

Bör korten tilldelas förare eller fordon?

Använd den enhet som er fordonsflotta behöver styra och stämma av. Tilldelning per förare passar personligt ansvar; tilldelning per fordon kan förenkla delade rutter; poolkort kräver starkare kontroller för utlämning och avvikelser.

04

Hur ersätts förlorade kort?

Spärra den förlorade token i auktoriseringsplattformen, utfärda ett ersättningskort med en ny unik identifierare, uppdatera tilldelningen till förare eller fordon och spara en revisionslogg som kopplar samman ändringen.

05

Kan kortdata importeras i bulk?

Ja. Kom först överens om obligatoriska kolumner och tokenrepresentation. En leveransfil kan mappa UID, synligt kortnummer, batch och andra godkända fält för bulkimport till plattformen.

06

Registrerar kortet självt kWh och laddkostnad?

Vanligtvis inte. Laddstationen och administrationsplattformen skapar sessionsposten och faktureringsdata. Kortet tillhandahåller den token som används för att koppla sessionen till ett flottkonto.

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