Programa de credenciais para roaming

Roaming entre redes

Credenciais RFID físicas para programas de roaming em que os registos de tokens, os formatos de identificador e o estado do ciclo de vida se mantêm coerentes entre os sistemas do eMSP, do CPO e do hub.

Resultado do programa

Um cartão ou porta-chaves cujo registo de token, formato de identificador e estado do ciclo de vida se mantêm coerentes em todos os sistemas participantes.

Ver o produto recomendado

Concebido para

eMSP, CPO e plataformas de mobilidade com roaming bilateral ou através de hub

01

Camada de roaming

OCPI 2.2.1 / 2.3.0, OICP ou eMIP

02

Camada do posto

Leitor + OCPP + backend do CPO

03

Identidade

Registo de token controlado pelo emissor

04

Âmbito comercial

Os contratos e os direitos de utilização estão fora do cartão

Modelo operacional / 01

Acompanhe a credencial ao longo de toda a cadeia de autorização.

O cartão físico é apenas um dos elementos controlados. O comportamento do leitor, os registos da plataforma e as regras operacionais determinam se a conta correta é autorizada e rastreada.

Roaming entre redes
Um cartão ou porta-chaves cujo registo de token, formato de identificador e estado do ciclo de vida se mantêm coerentes em todos os sistemas participantes.
  1. 01

    Credencial emitida pelo eMSP

    O prestador de mobilidade atribui um cartão ou porta-chaves a um cliente e controla o respetivo estado no ciclo de vida.

  2. 02

    Posto de carregamento visitado

    O posto lê o cartão ou porta-chaves e reencaminha o identificador para o backend do CPO, através do fluxo de autorização que suporta.

  3. 03

    Camada de autorização do CPO

    O CPO consulta um repositório local de tokens ou pede autorização através da sua ligação de roaming.

  4. 04

    Ligação bilateral ou hub de roaming

    O OCPI, o OICP ou o eMIP transmitem informação de tokens, de autorização e das sessões relacionadas entre as partes contratadas.

  5. 05

    Retorno de sessões e CDR

    Os dados de sessão e de detalhe de carregamento regressam pela cadeia comercial; o cartão é apenas o elemento que desencadeia a identificação.

Matriz de especificação / 02

Decisões a fechar antes da produção.

Um caderno de requisitos pronto para produção indica o que tem de ser decidido, como será implementado e que evidências contarão para a aceitação.

01

Topologia de roaming

O que definir

Identifique os parceiros bilaterais, as ligações a hubs, os ambientes e as versões de protocolo.

Evidência de aceitação

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

02

Titularidade do token

O que definir

Defina o emissor, os identificadores de entidade/país, o tipo de token, a referência contratual e a autoridade sobre o ciclo de vida.

Evidência de aceitação

O token mantém-se globalmente único no 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/minúsculas e o comprimento permitido.

Evidência de aceitação

A saída do leitor, o registo no CSMS e a mensagem de roaming correspondem ao mesmo valor.

04

Modo de autorização

O que definir

Documente o envio de listas de identificadores autorizados, os pedidos em tempo real, a cache e o comportamento offline para cada parque de postos de CPO de destino.

Evidência de aceitação

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

05

Propagação de estados

O que definir

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

Evidência de aceitação

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

06

Reconciliação de sessões

O que definir

Especifique as referências utilizadas para reconciliar os registos de autorização, sessão e CDR.

Evidência de aceitação

As sessões-piloto regressam ao registo correto do cliente do eMSP, sem dados órfãos.

07

Gestão de exceções

O que definir

Atribua responsabilidades por tokens rejeitados, incompatibilidades de leitores, falhas de parceiros e sessões contestadas.

Evidência de aceitação

A equipa de apoio consegue rastrear uma falha nos registos do posto, do CPO, do hub e do eMSP.

Controlo de falhas / 03

Elimine desde a conceção os pontos de falha mais comuns.

A maioria dos lançamentos falhados não se deve à qualidade de impressão. Resulta de identificadores pouco claros, leitores não testados, responsabilidade incompleta pelos dados ou um controlo deficiente do ciclo de vida.

01

Um cartão não cria roaming

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

02

Normalize os identificadores uma única vez

As discrepâncias na ordem dos bytes, no preenchimento e nas maiúsculas/minúsculas são causas frequentes de falhas de autorização; fixe a representação antes da produção.

03

Teste os estados do ciclo de vida

Uma primeira aproximação bem-sucedida não basta. Valide os percursos de bloqueio, expiração, substituição e reativação na mesma rota.

04

Mantenha a liquidação fora das alegações sobre o cartão

A troca de CDR, as tarifas e a liquidação pertencem às plataformas de roaming e aos contratos, não ao fabrico de credenciais.

Percurso de entrega / 04

Do caderno de requisitos à operação controlada.

Cada fase deve terminar com evidências que possam ser analisadas pelas equipas de operações, de plataforma e de compras.

  1. 01

    Mapa da topologia

    Documente o emissor, os parceiros, os hubs, as versões de protocolo, a titularidade dos tokens e os contactos de apoio.

    Evidências

    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ências

    Rastreio integral do token

  3. 03

    Testes de estados

    Teste os cenários aceite, desconhecido, bloqueado, expirado, offline e de substituição.

    Evidências

    Matriz de resultados de autorização

  4. 04

    Lançamento no mercado

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

    Evidências

    Registo de mercados/parceiros aprovados

  5. 05

    Controlo de alterações

    Faça a gestão de novos parceiros, atualizações de protocolo e substituições sem alterar silenciosamente as regras de identidade física.

    Evidências

    Registo de interoperabilidade com controlo de versões

Fronteira de responsabilidades / 05

Separe o fabrico da operação da plataforma.

Uma fronteira bem definida evita que o cartão seja responsabilizado por decisões de configuração, de direitos de utilização ou de liquidação que pertencem a outras partes.

01

ChargeRFID / fabricante

Controla o material, o chip, a antena, a arte gráfica, a codificação, os dados variáveis, o controlo de qualidade por lote e o registo de produção aprovados.

02

Equipa do CPO, do eMSP ou do CSMS

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

03

Responsável pelo programa

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

Perguntas sobre o programa / 08

Questões que as equipas de compras e técnicas costumam resolver.

01Um cartão acabado de fabricar funciona automaticamente nas redes de roaming?

Não. O identificador da credencial tem de ser registado e autorizado através da ligação comercial e técnica entre o eMSP e o CPO. O fabrico produz o cartão ou porta-chaves; não cria um contrato de roaming nem direitos associados ao token.

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

O OCPP é sobretudo o protocolo entre o posto e o sistema de gestão. O OCPI liga CPO e eMSP para a troca de dados de roaming, como localizações, tokens, sessões, tarifas e CDR. O OICP e o eMIP disponibilizam interfaces de roaming alternativas.

03Que versão do OCPI deve o cartão suportar?

O cartão não implementa o OCPI. As plataformas participantes acordam a versão do OCPI, enquanto o cartão ou porta-chaves e o respetivo identificador têm de corresponder ao leitor e às regras de tokens utilizados por essas plataformas.

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

Sim, e essa é uma fonte frequente de falhas. A conversão hexadecimal/decimal, a ordem dos bytes, o preenchimento, os zeros à esquerda e as maiúsculas/minúsculas devem ficar fixados na especificação da interface e ser verificados de ponta a ponta.

Especificação controlada do programa: Cartões RFID para redes de carregamento OCPP

Partilhe o parque de leitores, as regras de identificadores, o requisito de segurança, a integração com a plataforma, o volume e os mercados de implementação. Enviaremos as perguntas necessárias para as amostras e para a aprovação da produção.