Forside/Alle produkter/Ladekort til elbilflåder
Ladekort til elbilflåder — produktvisning 1
01 / 04

Adgangsmiddel til elbilopladning

Fremstillet efter specifikation

Ladekort til elbilflåder

Brandede RFID-identifikationsmidler til flådeopladning med unikke tokendata, nummerering pr. fører eller køretøj, bulkimport i platformen og kontrolleret genopfyldning.

FlådedriftTokendata i bulkGenopfyldning
Materiale
Genanvendt PVC, standard-PVC eller godkendt alternativ
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 dataformat, 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

Fysiske identifikationsmidler til administrerede elbilflåder

Et ladekort til elbilflåder er et fysisk token, der udstedes til en fører, et køretøj, et depot eller et omkostningssted, så ladesessioner kan henføres og styres af en flåde- eller e-mobilitetsplatform. Kortet identificerer kontoen; sessionsposter, priser, grænser og rapportering håndteres normalt i backend og gemmes ikke på kortet.

Et flådekort kan bruges på en operatørs egne ladepunkter eller i et roamingprogram. Roaming opstår gennem kommercielle og tekniske relationer mellem eMSP'er, CPO'er og hubs – ikke ved at trykke et logo eller vælge en bestemt kortkrop. Identifikationsdata skal registreres og routes via den platform, der administrerer disse relationer.

01

Tildelingsmodel

Beslut, om hvert token tilhører en fører, et køretøj, en pulje, et depot eller et omkostningssted, og hvordan overdragelser registreres.

02

Netværksomfang

Oplist depot-, arbejdsplads-, offentlige og roamingmiljøer, og identificér den platform, der er ansvarlig for autorisation.

03

Livscykluskontroller

Definér procedurer for udstedelse, aktivering, suspendering, tab, erstatning, udløb og returnering, før kortene distribueres.

04

Afstemningsfelter

Afstem synlige kortnumre, tokenposter og referencer i flådesystemet, så afvigelser hurtigt kan spores.

Funktioner og muligheder / 02

Hvad der kan specificeres.

Det fysiske kort kan struktureres, så supportarbejdet reduceres, og det integreres gnidningsfrit med onboarding og genopfyldning i flåden.

01

Nummerering pr. fører eller køretøj

Synlige referencer kan følge operatørens tildelingsmodel uden at eksponere det elektroniske UID som supportidentifikator.

02

Tokendata i bulk

Strukturerede leveringsfiler understøtter import, tildeling og aktivering i flåde- eller e-mobilitetsplatformen.

03

Specialtilpasset programdesign

Brand, supportinstruktioner, nødinformation og påkrævet juridisk tekst kan organiseres på kortet.

04

Holdbare kortmaterialer

Genanvendt PVC og alternative kortkroppe kan vælges ud fra, hvordan kortene håndteres i pung, køretøj og depot.

05

Muligheder for kort og ladebrikker

Blandede formfaktorer kan betjene forskellige førergrupper og samtidig følge ét kontrolleret workflow for tokendata.

06

Planlagt genopfyldning

Nummerserier, designmastere og pakkeregler kan bevares til erstatnings- og vækstbatches.

Teknisk egnethed / 03

Kortet er ét lag i flådens ladekontrol

Brugbar rapportering og roaming afhænger af systemerne omkring identifikationsmidlet. Kortet skal give disse systemer et stabilt, sporbart token.

01

Tildelingen ligger i platformen

Rapportering pr. fører, pr. køretøj og pr. omkostningssted opnås ved at knytte korttokenet til den rette flådepost.

02

Roaming kræver registrering i platformen

Et produceret kort fungerer kun på tværs af netværk, når dets token er registreret og accepteret via den relevante eMSP-, CPO- eller roamingrelation.

03

Et erstatningskort skal have en ny identifikator

Mistede kort bør spærres og erstattes med et nyt unikt token; et genoptryk af det samme synlige nummer kræver ikke genbrug af det elektroniske UID.

04

Offline autorisation kræver styring

Hvor ladestandere bruger lokale tokenlister, skal synkroniseringstidspunkter defineres, og det skal fastlægges, hvad der skal ske, når et kort er spærret.

05

Dataformater bør testes i batchskala

Validér overskrifter, separatorer, foranstillede nuller og repræsentation af identifikatorer, før produktionsfilen importeres.

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, standard-PVC eller godkendt alternativ
Størrelse
CR80 / ISO ID-1 nominelt format (85.60 × 53.98 mm)

Teknisk

Frekvens
Typisk 13.56 MHz / ISO 14443A; bekræftes med flådens bestand af læsere
Læseafstand
Afhænger af læser og installeret antenne; prøvevalidering påkrævet
Sikkerhed
Ren UID eller sikker applikation afhængigt af platform- og læserdesign

Bestilling

MOQ
Fra 500 stk., afhængigt af materiale og chip
Leveringstid
Bekræftes efter godkendelse af dataformat, design og prøve

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

Hvilke oplysninger gemmes på et ladekort til flåder?

Mange programmer bruger kun en chipidentifikator som token. Førerdata, køretøjsdata, tariffer og sessionshistorik forbliver i backend. Sikre applikationer kan gemme yderligere data, når læseren og systemet er designet til at bruge dem.

02

Kan ét flådekort fungere på flere ladenetværk?

Ja, når flådens e-mobilitetsudbyder eller platform har de nødvendige roaming- eller bilaterale netværksrelationer og registrerer tokenet korrekt. Det fysiske kort skaber ikke i sig selv netværksadgang.

03

Bør kort tildeles førere eller køretøjer?

Brug den enhed, som flåden skal kontrollere og afstemme. Tildeling til fører passer til personligt ansvar; tildeling til køretøj kan forenkle delte ruter; puljekort kræver stærkere udleverings- og afvigelseskontroller.

04

Hvordan erstattes mistede kort?

Spær det mistede token i autorisationsplatformen, udsted et erstatningskort med en ny unik identifikator, opdatér tildelingen til fører eller køretøj, og bevar et revisionsspor, der dokumenterer ændringen.

05

Kan kortdata importeres i bulk?

Ja. Aftal først de påkrævede kolonner og tokenrepræsentationen. En leveringsfil kan knytte UID, synligt kortnummer, batch og andre godkendte felter sammen til bulkimport i platformen.

06

Registrerer kortet selv kWh og ladeomkostninger?

Normalt ikke. Ladestanderen og administrationsplatformen opretter sessionsposten og faktureringsdata. Kortet leverer det token, der bruges til at knytte sessionen til en flådekonto.

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