Program för utfärdande för CPO och eMSP

Program för identifieringsmedel för CPO och eMSP

White label-kort och nyckelbrickor utformade kring ert varumärke, identifierarformat, plattformsimport, lanseringsvolym och flöde för efterbeställningar.

Programresultat

Ett repeterbart program för utfärdande som kopplar samman fysiskt lager, tokenposter, varumärkestillgångar och påfyllning.

Granska rekommenderad produkt

Utformat för

Laddoperatörer, eMobility-tjänsteleverantörer och white label-mobilitetsvarumärken

01

Programroll

CPO, eMSP eller kombinerad verksamhet

02

Tokenöverlämning

Utfärdarpost, identifierare och status

03

Plattformslager

CSMS, kundplattform och roaminganslutningar

04

Leveransmodell

Lanseringslager, distribution och upprepade batcher

Driftmodell / 01

Följ identifieringsmedlet genom hela auktoriseringskedjan.

Det fysiska kortet är en kontrollerad komponent. Läsarens beteende, plattformens poster och driftreglerna avgör om rätt konto auktoriseras och spåras.

Program för identifieringsmedel för CPO och eMSP
Ett repeterbart program för utfärdande som kopplar samman fysiskt lager, tokenposter, varumärkestillgångar och påfyllning.
  1. 01

    Abonnent eller konto

    Tjänsteleverantören äger den kommersiella relationen, behörigheten och aktiveringsstatusen för föraren eller organisationen.

  2. 02

    Utfärdat kort eller utfärdad laddbricka

    Den fysiska id-bäraren har det godkända varumärket, ett synligt serienummer och en läsarkompatibel identifierare.

  3. 03

    Station och CSMS

    Stationen läser id-bäraren och CSMS tillämpar lokal, cachad eller central auktorisering enligt sin implementering.

  4. 04

    eMSP:ns kundplattform

    Id-bärarposten skapas, tilldelas, aktiveras och görs tillgänglig för kundtjänst- och ersättningsflöden.

  5. 05

    Roaminganslutning

    Där avtal finns delas tokendata och status med CPO-partner bilateralt eller via en roaminghubb.

Specifikationsmatris / 02

Beslut att fatta före produktion.

En produktionsklar kravbeskrivning anger vad som måste beslutas, hur det ska genomföras och vilka underlag som räknas som godkännande.

01

Operatörsroll

Vad som ska definieras

Ange om programmet agerar som CPO, eMSP, flottjänst, white label-utfärdare eller en kombination av dessa.

Underlag för godkännande

Ägarskapet för token-, kund-, stations- och supportposter är entydigt.

02

Tokennamnrymd

Vad som ska definieras

Definiera utfärdare, lands- och partsreferenser, tokentyp och de unikhetsregler som målplattformen använder.

Underlag för godkännande

En provpost godkänns utan kollision eller tyst omformatering.

03

Stationskompatibilitet

Vad som ska definieras

Dokumentera läsarteknik samt de OCPP-versioner och auktoriseringsfunktioner som CSMS använder.

Underlag för godkännande

Prov-id-bärare klarar de avsedda online- och offlinetesterna på stationen.

04

Datautbyte

Vad som ska definieras

Godkänn UID-representation, kundreferens, synligt serienummer, status och schema för importfilen.

Underlag för godkännande

Produktionsexporten klarar plattformsvalideringen och avstämningen av antal rader.

05

Utfärdandestatus

Vad som ska definieras

Välj om lagret levereras inaktivt, förtilldelat, förpackat per kund eller i bulk.

Underlag för godkännande

Aktiveringsansvar och förvaringsansvar registreras vid varje överlämning.

06

Varumärkessystem

Vad som ska definieras

Styr versioner av tryckoriginal, språkvarianter, supportuppgifter, juridiska märkningar och zoner för variabel data.

Underlag för godkännande

Ett signerat korrektur av tryckoriginalet och ett fysiskt godkännande av färg och prov sparas.

07

Påfyllning

Vad som ska definieras

Reservera identifierarintervall och definiera minimilager, ledtid och kontroller för efterbeställningar.

Underlag för godkännande

En upprepad batch kan tillverkas utan att specifikationen återskapas eller poster dupliceras.

Felkontroller / 03

Konstruera bort de vanligaste felkällorna.

De flesta misslyckade lanseringar beror inte på tryckkvaliteten. De beror på otydliga identifierare, otestade läsare, ofullständigt dataägarskap eller bristande livscykelkontroll.

01

Aktivera inte för tidigt

Håll tillverknings-, distributions- och aktiveringsstatus åtskilda så att lagerförluster inte skapar aktiva id-bärare.

02

Stäm av varje datafil

Antal, UID, synligt serienummer, förpackningstilldelning och importresultat ska stämma överens innan utlämning till kund.

03

Versionshantera varumärkes- och databriefen

Hantera tryckoriginal, tokenregler och förpackning som en enda kontrollerad release. En partiell ändring kan göra programposten ogiltig.

04

Behåll det godkända referensprovet

Behåll en godkänd id-bärare och en kodad post som jämförelsepunkt för produktion och framtida påfyllning.

Leveransväg / 04

Gå från kravbeskrivning till kontrollerad drift.

Varje fas bör avslutas med underlag som kan granskas av drift-, plattforms- och inköpsteam.

  1. 01

    Programdefinition

    Bekräfta roller, marknader, användargrupper, tokenägarskap och supportflöden.

    Underlag

    Signerad drift- och databrief

  2. 02

    Teknisk utformning av id-bäraren

    Välj format, chip, hantering av identifierare, visuellt serienummer och förpackningsupplägg.

    Underlag

    Läsartestade prov-id-bärare

  3. 03

    Plattformspilot

    Importera provtokenposter och testa aktivering, auktorisering, spärrning och ersättning.

    Underlag

    Godkänd import och testlogg

  4. 04

    Lanseringsleverans

    Tillverka, stäm av och förpacka den första kontrollerade batchen för utfärdande.

    Underlag

    Batch-QC, datamanifest och leveranspost

  5. 05

    Påfyllning

    Övervaka lager, reservera intervall och upprepa den godkända konstruktionen under ändringskontroll.

    Underlag

    Versionshanterat paket för efterbeställning

Ansvarsgräns / 05

Skilj tillverkning från plattformsdrift.

En tydlig gräns förhindrar att kortet får skulden för konfigurations-, behörighets- eller avräkningsbeslut som ligger någon annanstans.

01

ChargeRFID / tillverkare

Kontrollerar godkänt material, chip, antenn, tryckoriginal, kodning, variabla data, batchkvalitetskontroll och produktionsdokumentation.

02

CPO-, eMSP- eller CSMS-team

Definierar accepterat identifierarformat, läsarbeteende, tokenimport, auktoriseringsstatusar, säkerhetsapplikation och teknisk acceptans.

03

Programägare

Äger tilldelning, aktivering, avtal, åtkomstpolicy, taxor, kundsupport, godkännande av ersättningskort och beslut vid livscykelns slut.

Tekniskt bibliotek / 07

Fortsätt fördjupa dig i implementeringen.

Dessa källor definierar den omgivande tekniken och driftgränssnitten. ChargeRFID tillverkar fysiska identifieringsmedel; plattformskonfiguration, roamingavtal och certifiering av laddstationer ligger hos respektive operatörer och leverantörer.

Programfrågor / 08

Frågor som inköps- och teknikteam brukar reda ut.

01Vem skapar kund- och tokenposten?

CPO:n, eMSP:n eller dess plattform skapar och kontrollerar den kommersiella tokenposten. ChargeRFID kan koda de överenskomna id-uppgifterna och tillhandahålla en avstämd importfil, men aktiverar inte abonnemang och beviljar inte nätverksbehörighet.

02Kan korten levereras inaktiva?

Ja. Inaktivt bulklager, förtilldelade paket och distribution på kundnivå är olika driftmodeller. Aktiveringsstatus och överlämning av förvaringsansvar bör specificeras före produktion.

03Är ett RFID-kort i sig OCPP-kompatibelt?

Nej. OCPP kopplar samman laddstationen och managementsystemet. Kortet måste vara kompatibelt med stationens läsare och dess identifierare måste passa de auktoriseringsregler som implementeras via OCPP.

04Vad bör sparas inför efterbeställningar?

Spara godkänt material, chip, antenn, tryckoriginal, färgmål, identifierarregler, dataschema, förpackning, QC-kriterier och ett referensprov under en och samma programversion.

Styrd specifikation för kortprogram: RFID-kort för OCPP-laddnätverk

Dela information om läsarbestånd, regler för identifierare, säkerhetskrav, överlämning till plattformen, volym och marknader för utrullning. Vi återkommer med de frågor som behövs för prover och produktionsgodkännande.