Roaming de rede

Roaming de rede

Credenciais RFID físicas para programas de roaming nos quais registros de token, formato do identificador e status do ciclo de vida precisam permanecer coerentes entre sistemas eMSP, CPO e hubs.

Resultado do programa

Uma credencial física cujo registro de token, formato do identificador e estado do ciclo de vida permanecem consistentes entre os sistemas participantes.

Ver produto recomendado

Desenvolvido para

eMSPs, CPOs e plataformas de mobilidade que operam roaming bilateral ou por hubs

01

Camada de roaming

OCPI 2.2.1 / 2.3.0, OICP ou eMIP

02

Camada da estação

Leitor + OCPP + backend do CPO

03

Identidade

Registro de token controlado pelo emissor

04

Escopo comercial

Os contratos e as permissões de uso são externos ao cartão

Modelo operacional / 01

Acompanhe a credencial em toda a cadeia de autorização.

O cartão físico é apenas uma entrada controlada. O comportamento do leitor, os registros da plataforma e as regras operacionais determinam a autorização e a rastreabilidade da conta correta.

Roaming de rede
Uma credencial física cujo registro de token, formato do identificador e estado do ciclo de vida permanecem consistentes entre os sistemas participantes.
  1. 01

    Credencial emitida pelo eMSP

    O provedor de mobilidade vincula um cartão ou chaveiro RFID físico a um cliente e controla seu status ao longo do ciclo de vida.

  2. 02

    Estação de recarga visitada

    A estação lê a credencial e encaminha o identificador ao backend do CPO usando o fluxo de autorização que ela suporta.

  3. 03

    Camada de autorização do CPO

    O CPO consulta um repositório local de tokens ou solicita autorização por meio de sua conexão de roaming.

  4. 04

    Conexão bilateral ou hub de roaming

    OCPI, OICP ou eMIP transporta informações de tokens, autorizações e sessões relacionadas entre as partes contratantes.

  5. 05

    Retorno de sessões e CDR

    Os dados das sessões e dos detalhes de recarga retornam pela cadeia comercial; o cartão apenas inicia o processo de identificação.

Matriz de especificação / 02

Decisões que precisam ser fechadas antes da produção.

Um briefing pronto para produção define a decisão, sua implementação e a evidência necessária para aceitação.

01

Topologia de roaming

O que definir

Identifique os parceiros bilaterais, as conexões com hubs, os ambientes e as versões dos protocolos.

Evidência de aceitação

Cada rota prevista tem um responsável e um endpoint de teste.

02

Titularidade dos tokens

O que definir

Defina o emissor, os identificadores de parte e país, o tipo de token, a referência do contrato e a autoridade responsável pelo ciclo de vida.

Evidência de aceitação

O token permanece globalmente único dentro do ecossistema acordado.

03

Normalização do UID

O que definir

Acorde a representação hexadecimal ou decimal, a ordem dos bytes, o preenchimento, o uso de maiúsculas e minúsculas e o comprimento permitido.

Evidência de aceitação

A saída do leitor, o registro no CSMS e o conteúdo de dados do roaming correspondem ao mesmo valor.

04

Modo de autorização

O que definir

Documente o envio de listas de permissões, as solicitações em tempo real, o cache e o comportamento offline para cada parque de estações dos CPOs previstos.

Evidência de aceitação

Os estados aceito, bloqueado, expirado e desconhecido produzem o resultado esperado.

05

Propagação de status

O que definir

Defina como os tokens recém-emitidos, bloqueados, expirados e substituídos são transmitidos entre as partes.

Evidência de aceitação

Uma alteração de status chega ao CPO de teste dentro da janela operacional acordada.

06

Conciliação de sessões

O que definir

Especifique as referências usadas para conciliar os registros de autorização, sessão e CDR.

Evidência de aceitação

As sessões do piloto retornam ao cadastro correto do cliente no eMSP, sem dados órfãos.

07

Tratamento de exceções

O que definir

Defina os responsáveis por tokens rejeitados, incompatibilidades com leitores, indisponibilidade de parceiros e sessões contestadas.

Evidência de aceitação

A equipe de suporte consegue rastrear uma falha nos logs da estação, do CPO, do hub e do eMSP.

Controles de falha / 03

Elimine os pontos de falha mais comuns.

A maioria das falhas de lançamento não é causada pela qualidade de impressão. Elas decorrem de identificadores pouco claros, leitores não testados, definição incompleta da responsabilidade pelos dados ou controle deficiente do ciclo de vida.

01

Um cartão não cria acesso em roaming

O acesso à rede só existe depois que a conexão comercial e a distribuição ou autorização dos tokens estão estabelecidas.

02

Normalize os identificadores uma única vez

Divergências na ordem dos bytes, no preenchimento e no uso de maiúsculas e minúsculas são causas comuns de falhas de autorização; fixe a representação antes da produção.

03

Teste os estados do ciclo de vida

O sucesso na primeira aproximação não é suficiente. Valide os fluxos de bloqueio, expiração, substituição e reativação na mesma rota.

04

Não atribua a liquidação financeira ao cartão

A troca de CDR, as tarifas e a liquidação financeira são atribuições das plataformas e dos contratos de roaming, não da fabricação de credenciais.

Caminho de entrega / 04

Do briefing à operação controlada.

Cada fase deve terminar com evidências verificáveis por operações, plataforma e compras.

  1. 01

    Mapa da topologia

    Documente o emissor, os parceiros, os hubs, as versões dos protocolos, a titularidade dos tokens e os contatos de suporte.

    Evidência

    Matriz de responsabilidades de roaming

  2. 02

    Piloto de identificadores

    Produza um pequeno conjunto com valores conhecidos e compare as representações no leitor, no CSMS e no roaming.

    Evidência

    Rastreamento do token de ponta a ponta

  3. 03

    Teste de estados

    Teste os cenários de aceitação, token desconhecido, bloqueio, expiração, operação offline e substituição.

    Evidência

    Matriz de resultados de autorização

  4. 04

    Lançamento nos mercados

    Libere apenas os mercados e as rotas de parceiros que tenham concluído a aceitação.

    Evidência

    Cadastro aprovado de mercados e parceiros

  5. 05

    Controle de alterações

    Gerencie novos parceiros, atualizações de protocolos e substituições sem alterar silenciosamente as regras de identificação física.

    Evidência

    Registro versionado de interoperabilidade

Limite de responsabilidade / 05

Separe fabricação da operação da plataforma.

Um limite preciso evita responsabilizar o cartão por decisões sobre configuração, permissões de acesso ou liquidação que pertencem a outros sistemas.

01

ChargeRFID / fabricante

Controla material, chip, antena, arte, codificação, dados variáveis, QC de lote e registro de produção aprovados.

02

Equipe CPO, eMSP ou CSMS

Define formato do identificador, comportamento do leitor, importação de tokens, estados de autorização, aplicação de segurança e aceitação técnica.

03

Responsável pelo programa

É responsável pela atribuição, ativação, contratos, política de acesso, tarifas, suporte ao cliente, aprovação de substituições e decisões de fim de vida.

Um cartão recém-fabricado não passa a funcionar automaticamente em redes de roaming. O identificador da credencial precisa ser cadastrado e autorizado por meio da conexão comercial e técnica entre eMSP e CPO. A fabricação produz a credencial física; ela não cria um contrato de roaming nem o direito de uso do token.

Perguntas do programa / 08

Questões normalmente resolvidas pelas equipes de compras e técnica.

01Um cartão recém-fabricado funcionará automaticamente nas redes de roaming?

Não. O identificador da credencial deve ser cadastrado e autorizado por meio da conexão comercial e técnica entre eMSP e CPO. A fabricação produz a credencial física; ela não cria um contrato de roaming nem concede permissão de uso ao token.

02Qual é a diferença entre OCPP e OCPI?

OCPP é, principalmente, o protocolo entre a estação e o sistema de gerenciamento. OCPI conecta CPOs e eMSPs para a troca de dados de roaming, como localizações, tokens, sessões, tarifas e CDRs. OICP e eMIP oferecem interfaces alternativas de roaming.

03Qual versão de OCPI o cartão deve suportar?

O cartão não implementa OCPI. As plataformas participantes acordam a versão de OCPI, enquanto a credencial física e o identificador devem ser compatíveis com o leitor e com as regras de tokens usadas por essas plataformas.

04Um mesmo identificador pode ser representado de maneiras diferentes por sistemas diferentes?

Sim, e essa é uma causa comum de falhas. A conversão entre hexadecimal e decimal, a ordem dos bytes, o preenchimento, os zeros à esquerda e o uso de maiúsculas e minúsculas devem ser definidos na especificação da interface e verificados de ponta a ponta.

Transforme cartões RFID para redes de recarga OCPP em uma especificação de programa controlada.

Compartilhe o parque de leitores, as regras do identificador, o requisito de segurança, a entrega à plataforma, o volume e os mercados de implantação. Retornaremos com as perguntas necessárias para as amostras e a aprovação da produção.