Utstedelsesprogram for CPO og eMSP

Kort- og brikkeprogrammer for CPO og eMSP

White label-kort og nøkkelbrikker tilpasset merkevare, identifikatorformat, plattformimport, lanseringsvolum og arbeidsflyt for etterbestillinger.

Resultat for programmet

Et repeterbart utstedelsesprogram som knytter sammen fysisk lager, tokenposter, merkevareelementer og påfyll.

Se anbefalt produkt

Utviklet for

Ladeoperatører, eMobility-tjenesteleverandører og white label-mobilitetsmerker

01

Programrolle

CPO, eMSP eller kombinert drift

02

Token-overlevering

Utstederpost, identifikator og status

03

Plattformlag

CSMS, kundeplattform og roamingforbindelser

04

Forsyningsmodell

Lanseringslager, distribusjon og gjentatte batcher

Driftsmodell / 01

Følg ladekortet eller ladebrikken gjennom hele autorisasjonskjeden.

Det fysiske kortet er én kontrollert faktor. Leseratferd, plattformregistre og driftsregler avgjør om riktig konto blir autorisert og sporet.

Kort- og brikkeprogrammer for CPO og eMSP
Et repeterbart utstedelsesprogram som knytter sammen fysisk lager, tokenposter, merkevareelementer og påfyll.
  1. 01

    Abonnent eller konto

    Tjenesteleverandøren eier det kommersielle forholdet, rettigheten og aktiveringsstatusen for sjåføren eller organisasjonen.

  2. 02

    Utstedt kort eller nøkkelbrikke

    Selve ladekortet eller ladebrikken har godkjent merkevaredesign, synlig serienummer og en identifikator som er kompatibel med leseren.

  3. 03

    Stasjon og CSMS

    Stasjonen leser ladekortet eller ladebrikken, og CSMS-et anvender lokal, bufret eller sentral autorisasjon avhengig av implementeringen.

  4. 04

    eMSP-kundeplattform

    Posten for ladekortet eller ladebrikken opprettes, tildeles, aktiveres og gjøres tilgjengelig i arbeidsflytene for kundeservice og utskifting.

  5. 05

    Roamingforbindelse

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

Spesifikasjonsmatrise / 02

Beslutninger som må tas før produksjon.

En produksjonsklar kravbeskrivelse angir hva som må avgjøres, hvordan det skal gjennomføres og hvilken dokumentasjon som teller som godkjenning.

01

Operatørrolle

Hva som må defineres

Angi om programmet opptrer som CPO, eMSP, bilparktjeneste, white label-utsteder eller en kombinasjon.

Akseptansedokumentasjon

Eierskapet til token-, kunde-, stasjons- og supportposter er entydig.

02

Token-navnerom

Hva som må defineres

Definer utsteder, lands-/partsreferanser, tokentype og unikhetsregler som brukes av målplattformen.

Akseptansedokumentasjon

En prøvepost aksepteres uten kollisjon eller stille omformatering.

03

Stasjonskompatibilitet

Hva som må defineres

Dokumenter leserteknologi samt OCPP-versjonene og autorisasjonsfunksjonene som brukes av CSMS.

Akseptansedokumentasjon

Prøveeksemplarene gjennomfører de planlagte stasjonstestene med og uten nettforbindelse.

04

Datautveksling

Hva som må defineres

Godkjenn UID-representasjon, kundereferanse, synlig serienummer, status og skjema for importfil.

Akseptansedokumentasjon

Produksjonseksporten består plattformvalidering og avstemming av antall rader.

05

Utstedelsesstatus

Hva som må defineres

Velg om lageret leveres inaktivt, forhåndstildelt, pakket per kunde eller i bulk.

Akseptansedokumentasjon

Ansvar for aktivering og forvaring registreres ved hver overlevering.

06

Merkevaresystem

Hva som må defineres

Styr trykkversjoner, språkvarianter, supportopplysninger, juridiske merker og soner for variable data.

Akseptansedokumentasjon

Et signert trykkprøveark og fysisk godkjenning av farge/prøve oppbevares.

07

Etterfylling

Hva som må defineres

Reserver identifikatorserier og definer kontroller for minimumslager, ledetid og gjentatte bestillinger.

Akseptansedokumentasjon

En gjentatt batch kan produseres uten å gjenskape spesifikasjonen eller duplisere poster.

Feilkontroll / 03

Fjern de vanlige feilkildene allerede i designet.

De fleste mislykkede lanseringer skyldes ikke trykkvalitet. De kommer av uklare identifikatorer, utestede lesere, ufullstendig dataeierskap eller svak livssykluskontroll.

01

Ikke aktiver for tidlig

Hold produksjons-, distribusjons- og aktiveringsstatus atskilt, slik at svinn fra lageret ikke fører til aktive ladekort eller ladebrikker.

02

Avstem hver datafil

Antall, UID, synlig serienummer, pakketildeling og importresultat bør stemme før utstedelse til kunde.

03

Versjoner merkevare- og databriefen

Behandle trykk, tokenregler og emballasje som én kontrollert utgivelse. En delvis endring kan gjøre programposten ugyldig.

04

Oppbevar referanseprøven

Oppbevar et godkjent eksemplar og den tilhørende kodede posten som sammenligningsgrunnlag for produksjon og fremtidige etterbestillinger.

Leveranseløp / 04

Gå fra kravbeskrivelse til kontrollert drift.

Hver fase bør avsluttes med dokumentasjon som kan gjennomgås av drifts-, plattform- og innkjøpsteamene.

  1. 01

    Programdefinisjon

    Bekreft roller, markeder, brukergrupper, tokeneierskap og arbeidsflyter for support.

    Dokumentasjon

    Signert drifts- og databrief

  2. 02

    Utvikling av ladekort og ladebrikker

    Velg format, chip, identifikatorhåndtering, synlig serienummer og emballasjeløsning.

    Dokumentasjon

    Lesertestede prøveeksemplarer

  3. 03

    Plattformpilot

    Importer prøveposter for token og test aktivering, autorisasjon, sperring og utskifting.

    Dokumentasjon

    Godkjent import og testlogg

  4. 04

    Lanseringsdistribusjon

    Produser, avstem og pakk den første kontrollerte utstedelsesbatchen.

    Dokumentasjon

    Batch-QC, datamanifest og forsendelsespost

  5. 05

    Etterfylling

    Overvåk lageret, reserver identifikatorserier og gjenta den godkjente produksjonen under endringskontroll.

    Dokumentasjon

    Versjonert pakke for gjentatte bestillinger

Ansvarsgrense / 05

Skill produksjon fra plattformdrift.

En presis ansvarsgrense hindrer at kortet får skylden for konfigurasjons-, rettighets- eller oppgjørsbeslutninger som ligger andre steder.

01

ChargeRFID / produsent

Kontrollerer godkjent materiale, chip, antenne, trykkdesign, koding, variable data, kvalitetskontroll av partier og produksjonsregister.

02

CPO-, eMSP- eller CSMS-team

Definerer godkjent identifikatorformat, leseratferd, token-import, autorisasjonsstatuser, sikkerhetsapplikasjon og teknisk godkjenning.

03

Programeier

Eier tildeling, aktivering, avtaler, tilgangspolicy, tariffer, kundestøtte, godkjenning av erstatninger og beslutninger om utfasing.

Teknisk bibliotek / 07

Les videre om implementeringen.

Disse kildene definerer den omkringliggende teknologien og driftsgrensesnittene. ChargeRFID produserer fysiske RFID-kort og ladebrikker; plattformkonfigurasjon, roamingavtaler og sertifisering av ladestasjoner ligger hos de aktuelle operatørene og leverandørene.

Programspørsmål / 08

Spørsmål innkjøps- og tekniske team vanligvis avklarer.

01Hvem oppretter kunde- og tokenposten?

CPO-en, eMSP-en eller plattformen deres oppretter og kontrollerer den kommersielle tokenposten. ChargeRFID kan kode de avtalte dataene på kortene og brikkene og levere en avstemt importfil, men aktiverer ikke abonnementer og tildeler ikke nettverksrettigheter.

02Kan kortene leveres inaktive?

Ja. Inaktivt bulklager, forhåndstildelte pakker og distribusjon på kundenivå er ulike driftsmodeller. Aktiveringsstatus og overlevering av forvaring bør spesifiseres før produksjon.

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

Nei. OCPP forbinder ladestasjonen og styringssystemet. Kortet må være kompatibelt med stasjonens leser, og identifikatoren må passe autorisasjonsreglene som er implementert via OCPP.

04Hva bør oppbevares for gjentatte bestillinger?

Oppbevar godkjent materiale, chip, antenne, trykk, fargemål, identifikatorregler, dataskjema, emballasje, QC-kriterier og en referanseprøve under én programversjon.

Styrt spesifikasjon for kortprogram: RFID-kort for OCPP-ladenettverk

Del informasjon om leserpark, identifikatorregler, sikkerhetskrav, plattformoverlevering, volum og utrullingsmarkeder. Vi sender deg spørsmålene som trengs for prøver og produksjonsgodkjenning.