Udstedelsesprogram for CPO'er og eMSP'er

Programmer for CPO'er og eMSP'er

White label-kort og ladebrikker tilpasset jeres brand, identifikatorformat, platformimport, lanceringsvolumen og genbestillingsworkflow.

Programmets resultat

Et gentageligt udstedelsesprogram, der forbinder fysisk lager, tokenregistreringer, brandaktiver og genopfyldning.

Se anbefalet produkt

Udviklet til

Ladeoperatører (CPO), eMobility-serviceudbydere og white label-mobilitetsbrands

01

Programrolle

CPO, eMSP eller kombineret drift

02

Token-overlevering

Udstederregistrering, identifikator og status

03

Platformslag

CSMS, kundeplatform og roamingforbindelser

04

Forsyningsmodel

Lanceringslager, ordrehåndtering og efterfølgende produktionsserier

Driftsmodel / 01

Følg identifikationsmidlet gennem hele autorisationskæden.

Det fysiske kort er ét kontrolleret input. Læserens adfærd, platformens registreringer og driftsreglerne afgør, om den korrekte konto autoriseres og spores.

Programmer for CPO'er og eMSP'er
Et gentageligt udstedelsesprogram, der forbinder fysisk lager, tokenregistreringer, brandaktiver og genopfyldning.
  1. 01

    Abonnent eller konto

    Serviceudbyderen ejer den kommercielle relation, rettigheden og aktiveringsstatussen for føreren eller organisationen.

  2. 02

    Udstedt kort eller ladebrik

    Det fysiske adgangsmiddel bærer det godkendte brand, et synligt serienummer og en læserkompatibel identifikator.

  3. 03

    Ladestander og CSMS

    Ladestanderen aflæser adgangsmidlet; CSMS'et anvender lokal, cachet eller central autorisation i henhold til sin implementering.

  4. 04

    eMSP-kundeplatform

    Registreringen af adgangsmidlet oprettes, tildeles, aktiveres og gøres tilgængelig for kundeservice- og udskiftningsworkflows.

  5. 05

    Roamingforbindelse

    Hvor det er aftalt, deles tokendata og status med CPO-partnere bilateralt eller via en roaminghub.

Specifikationsmatrix / 02

Beslutninger, der skal træffes før produktion.

En produktionsklar brief angiver, hvad der skal besluttes, hvordan det implementeres, og hvilken dokumentation der gælder som accept.

01

Operatørrolle

Hvad skal defineres

Angiv, om programmet fungerer som CPO, eMSP, flådeservice, white label-udsteder eller en kombination.

Acceptdokumentation

Ejerskabet af token-, kunde-, ladestander- og supportregistreringer er entydigt.

02

Token-navnerum

Hvad skal defineres

Definér udsteder, lande-/partsreferencer, tokentype og unikhedsregler, som den tilsigtede platform anvender.

Acceptdokumentation

En prøveregistrering accepteres uden kollision eller stiltiende omformatering.

03

Ladestanderkompatibilitet

Hvad skal defineres

Dokumentér læserteknologi samt de OCPP-versioner og autorisationsfunktioner, som CSMS'et anvender.

Acceptdokumentation

Prøveadgangsmidler gennemfører de tilsigtede online- og offlinetests på ladestanderen.

04

Dataudveksling

Hvad skal defineres

Godkend UID-repræsentation, kundereference, synligt serienummer, status og skema for importfil.

Acceptdokumentation

Produktionseksporten består platformsvalidering og afstemning af rækkeantal.

05

Udstedelsestilstand

Hvad skal defineres

Vælg, om lageret leveres inaktivt, forhåndstildelt, pakket pr. kunde eller i bulk.

Acceptdokumentation

Ansvar for aktivering og opbevaring registreres ved hver overlevering.

06

Brandsystem

Hvad skal defineres

Styr grafikversioner, sprogvarianter, supportoplysninger, juridiske mærkninger og zoner til variable data.

Acceptdokumentation

En underskrevet grafikkorrektur og en fysisk farve-/prøvegodkendelse gemmes.

07

Genopfyldning

Hvad skal defineres

Reservér identifikatorintervaller, og definér kontroller for minimumslager, leveringstid og genbestilling.

Acceptdokumentation

En gentaget batch kan produceres uden at genskabe specifikationen eller duplikere registreringer.

Fejlkontrol / 03

Design de typiske fejlpunkter væk.

De fleste mislykkede lanceringer skyldes ikke trykkvaliteten. De skyldes uklare identifikatorer, utestede læsere, uklart dataejerskab eller svag livscyklusstyring.

01

Aktivér ikke for tidligt

Adskil status for produktion, ordrehåndtering og aktivering, så svind på lageret ikke resulterer i aktive identifikationsmidler.

02

Afstem hver datafil

Antal, UID, synligt serienummer, pakketildeling og importresultat bør stemme overens før udlevering til kunden.

03

Versionér brand- og databriefen

Behandl grafik, tokenregler og emballage som én kontrolleret udgivelse; en delvis ændring kan gøre programregistreringen ugyldig.

04

Bevar masterprøven

Behold et godkendt adgangsmiddel og den kodede registrering som sammenligningsgrundlag for produktion og fremtidig genopfyldning.

Leveringsforløb / 04

Gå fra brief til kontrolleret drift.

Hver fase bør afsluttes med dokumentation, som drifts-, platform- og indkøbsteams kan gennemgå.

  1. 01

    Programdefinition

    Bekræft roller, markeder, brugergrupper, tokenejerskab og supportworkflows.

    Dokumentation

    Underskrevet drifts- og databrief

  2. 02

    Udvikling af adgangsmiddel

    Vælg format, chip, identifikatorhåndtering, visuelt serienummer og emballageløsning.

    Dokumentation

    Læsertestede prøver af adgangsmidler

  3. 03

    Platformspilot

    Importér prøveregistreringer af tokens, og test aktivering, autorisation, spærring og udskiftning.

    Dokumentation

    Accepteret import og testlog

  4. 04

    Ordrehåndtering ved lancering

    Producér, afstem og pak den første kontrollerede udstedelsesbatch.

    Dokumentation

    Batch-QC, datamanifest og forsendelsesregistrering

  5. 05

    Genopfyldning

    Overvåg lageret, reservér identifikatorintervaller, og gentag den godkendte opbygning under ændringsstyring.

    Dokumentation

    Versioneret genbestillingspakke

Ansvarsgrænse / 05

Adskil produktion fra platformdrift.

En præcis grænse forhindrer, at kortet får skylden for konfigurations-, rettigheds- eller afregningsbeslutninger, der ligger andre steder.

01

ChargeRFID / producent

Styrer det godkendte materiale, chip, antenne, tryklayout, kodning, variable data, batch-QC og produktionsregistrering.

02

CPO-, eMSP- eller CSMS-team

Definerer det accepterede identifikatorformat, læseradfærd, tokenimport, autorisationsstatusser, sikkerhedsapplikation og teknisk accept.

03

Programejer

Ejer tildeling, aktivering, kontrakter, adgangspolitik, takster, kundesupport, godkendelse af erstatning og beslutninger om udfasning.

Teknisk bibliotek / 07

Fortsæt research om implementeringen.

Disse kilder definerer den omgivende teknologi og de driftsmæssige grænseflader. ChargeRFID producerer fysiske identifikationsmidler; platformkonfiguration, roamingaftaler og certificering af ladestationer ligger hos de relevante operatører og leverandører.

Programspørgsmål / 08

Spørgsmål, som indkøbs- og tekniske teams typisk afklarer.

01Hvem opretter kunde- og tokenregistreringen?

CPO'en, eMSP'en eller dennes platform opretter og styrer den kommercielle tokenregistrering. ChargeRFID kan kode de aftalte data i adgangsmidlet og levere en afstemt importfil, men aktiverer ikke abonnementer og giver ikke netværksrettigheder.

02Kan kort leveres inaktive?

Ja. Inaktivt bulklager, forhåndstildelte pakker og ordrehåndtering på kundeniveau er forskellige driftsmodeller. Aktiveringstilstanden og overdragelsen af opbevaringsansvaret bør specificeres før produktion.

03Er et RFID-kort i sig selv OCPP-kompatibelt?

Nej. OCPP forbinder ladestanderen og administrationssystemet. Kortet skal være kompatibelt med ladestanderens læser, og dets identifikator skal passe til de autorisationsregler, der er implementeret via OCPP.

04Hvad bør gemmes til genbestillinger?

Gem det godkendte materiale, chip, antenne, grafik, farvemål, identifikatorregler, dataskema, emballage, QC-kriterier og en masterprøve under én programversion.

Styret specifikation for kortprogram: RFID-kort til OCPP-ladenetværk

Del oplysninger om læserpark, regler for identifikatorer, sikkerhedskrav, overdragelse til platform, mængde og markeder for udrulning. Vi vender tilbage med de spørgsmål, der er nødvendige for prøver og produktionsgodkendelse.