Como configurar o acesso RFID em carregadores comerciais de veículos elétricos

Para configurar o acesso RFID em carregadores comerciais de veículos elétricos, confirme que o leitor é compatível com sua credencial, capture o identificador que o carregador realmente informa, cadastre esse valor na plataforma de recarga, atribua os direitos de acesso necessários e teste a sessão de recarga completa. Depois, teste o que acontece quando a conexão falha e quando um cartão é revogado.

Encomende o lote de produção depois que uma amostra representativa passar por esse procedimento. Uma leitura bem-sucedida comprova apenas parte do resultado. Seu registro de aceitação também deve demonstrar o ponto de recarga correto, a conta, o registro de energia e o comportamento de encerramento.

Este guia aborda a gestão de acesso depois que um instalador qualificado instalou e colocou os equipamentos de recarga em operação. Ele se destina à equipe que conecta credenciais físicas a um sistema de gestão de recarga.

Entenda qual sistema toma cada decisão

Em um fluxo de autorização online, o leitor RFID obtém um identificador, a estação de recarga o encaminha a um sistema de gestão de estações de recarga, ou CSMS, e a plataforma retorna um resultado de autorização. O OCPP rege a comunicação entre a estação e esse sistema de gestão. A interface de rádio entre cartão e leitor é uma parte separada da integração. Consulte a visão geral do protocolo da Open Charge Alliance.

Defina uma pessoa responsável por cada camada. Um fornecedor de cartões pode entregar a credencial física e o arquivo de identificadores acordados; o integrador dos carregadores confirma o comportamento do leitor; o operador da plataforma controla o cadastro das contas e as permissões. Registre quem resolve uma divergência antes do início do comissionamento.

1. Confirme os recursos do leitor e de autorização

Solicite a especificação do leitor para o modelo exato de carregador, a revisão de hardware e o firmware instalado. Registre os padrões sem contato compatíveis, o modo de credencial utilizado e qualquer conversão configurável de identificador. Uma descrição como “compatível com RFID” deixa essas perguntas em aberto.

O NFC opera a 13,56 MHz e abrange várias tecnologias sem contato, incluindo ISO/IEC 14443 Type A, Type B e ISO/IEC 15693. Portanto, uma frequência compatível, por si só, é uma especificação de compra incompleta. Verifique a compatibilidade entre a tecnologia real do cartão e a implementação do leitor. A visão geral técnica do NFC Forum explica esses protocolos subjacentes.

Em seguida, determine o que a estação e o backend realmente implementam:

A certificação OCPP precisa ser analisada por funcionalidade. A atualização da OCA de dezembro de 2025 situa Local List Management entre os recursos opcionais do perfil OCPP 2.0.1 Core. Assim, o programa de certificação atualizado não garante que toda estação certificada tenha suporte à lista local. A nota de aplicação OCPP 2.Lite, seção C da OCA também explica que o cache de autorização pode ser omitido e que as implementações podem oferecer diferentes métodos de autorização.

Solicite o escopo do certificado e o Protocol Implementation Conformance Statement, quando disponíveis, e confira sua correspondência com o software instalado. Guarde essas evidências junto com a configuração do local.

A OCA publica atualmente pacotes OCPP 1.6, 2.0.1 e 2.1. Os exemplos abaixo tratam especificamente de 1.6 e 2.0.1; use a especificação correspondente para uma instalação 2.1. Confira os downloads oficiais e as erratas durante o comissionamento ou uma atualização.

2. Capture o identificador do carregador real

Comece com um pequeno conjunto de cartões de teste identificáveis. Mantenha a referência impressa do cartão separada do valor eletrônico: um número de série visível como CRF-TEST-0042 é útil para o suporte, mas sua relação com o identificador do backend deve ser documentada.

Estes fragmentos ilustram o payload de uma solicitação de autorização OCPP online com um identificador fictício:

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

{"idToken":{"idToken":"04A1B2C3D4E5F7","type":"ISO14443"}}

Esses fragmentos omitem o enquadramento das mensagens WebSocket. Os esquemas oficiais definem um máximo de 20 caracteres para idTag em 1.6 e de 36 para a string idToken em 2.0.1; 2.0.1 também exige o tipo de token. Valide com o pacote OCPP 1.6 ou o pacote OCPP 2.0.1 Edition 4 usado na sua integração.

Um início autorizado localmente pode seguir uma sequência diferente de mensagens. Peça ao integrador que identifique onde a credencial e a decisão de autorização são registradas nesse modo.

3. Acorde a representação dos UIDs antes de importar os cartões

Para um token ISO14443, o OCPP 2.0.1 recomenda bytes UID hexadecimais com o byte 0 primeiro. Ainda é necessário verificar o comportamento dos produtos existentes: o guia de ativação OCPP da Wallbox especifica valores hexadecimais little-endian sem separadores para os produtos abrangidos pelo guia. Essa é uma instrução específica do produto, não uma regra universal de conversão. Consulte OCPP 2.0.1, seção de autorização C.1.1 e o guia de ativação da Wallbox, páginas 14 e 20.

Para esta sequência fictícia de sete bytes, as representações são:

A tabela mostra transformações, não quatro valores intercambiáveis no backend. Importe a representação exigida pela integração. Inverter bytes muda sua ordem em pares de caracteres; inverter caracteres individuais produz outro resultado.

Mantenha um mapeamento por escrito entre os dados do fornecedor, o log da estação e o campo de importação do backend. Inclua comprimento em bytes, notação hexadecimal ou decimal, ordem dos bytes, separadores e qualquer transformação explicitamente documentada. Preserve o arquivo de origem bruto. Evite truncamentos não documentados e não tente adivinhar bytes ausentes.

Verifique as configurações do dispositivo que transformam identificadores. O manual Wallbox eM4 WebAdmin, por exemplo, inclui a opção “Shorten UIDs” e alerta que as configurações de autorização podem ser alteradas pela interface local ou pelo backend. Consulte o manual Wallbox WebAdmin, página 23. Registre a configuração efetiva depois que os dois sistemas estiverem conectados.

Importe as colunas de identificadores nas planilhas como texto. O Excel pode remover zeros à esquerda e limita a precisão numérica a 15 dígitos significativos; nosso exemplo decimal tem 16 dígitos. Aplicar um formato de exibição depois que os dados foram alterados não recupera o identificador original. Siga as orientações da Microsoft para preservar dados de identificadores.

Use o conversor UID da ChargeRFID para examinar as representações e a ferramenta de conciliação de arquivos de credenciais para comparar os arquivos de produção e do backend. Confirme o mapeamento proposto com um log real do carregador antes de aplicá-lo ao lote.

4. Cadastre credenciais e atribua permissões comerciais

Crie o registro da credencial pelo processo documentado de cadastro ou importação da plataforma. Vincule-o ao motorista, veículo, departamento ou conta de cliente pretendidos, de acordo com a forma como sua operação atribui as recargas.

Para cada credencial piloto, registre:

Trate esses pontos como critérios separados de aceitação. Uma credencial pode estar no banco de dados sem ter a permissão de local ou a atribuição de conta pretendida. Da mesma forma, um início bem-sucedido não comprova que o arranjo correto de faturamento foi aplicado.

Use um cadastro com referência do lote, resultado de importação, motivo da exceção e revisor. Resolva valores duplicados e atribuições conflitantes antes da liberação. Adapte o modelo de entrega de UIDs à especificação real de importação da plataforma; a linha de exemplo contém dados de teste.

Para veículos compartilhados, acorde quem pode encerrar uma sessão. Os casos de teste OCPP 1.6 da OCA abrangem expressamente o encerramento com o cartão que iniciou a sessão e com outro cartão vinculado por um identificador pai correspondente. Teste o comportamento de grupo que pretende habilitar. Consulte os casos de teste OCTT 2026-02, seções 2.3.1 e 2.3.2.

5. Defina uma política explícita de acesso offline

Decida se a recarga deve continuar quando a estação não consegue alcançar seu sistema de gestão. Para um pátio de frota com acesso restrito, uma política inicial razoável é aceitar as credenciais pretendidas autorizadas localmente e rejeitar cartões desconhecidos durante uma interrupção. Confirme que o equipamento consegue implementar essa política antes de depender dela.

Um cache de autorização armazena informações de autorização obtidas em trocas anteriores. Uma lista local de autorização é gerenciada e sincronizada pelo backend. São mecanismos distintos. Limpar um não comprova que o outro foi atualizado. O OCPP 1.6 descreve a relação entre eles na seção 3.5 da especificação.

Estes são exemplos de nomes específicos de cada versão para discutir com o integrador, não um arquivo de configuração para colar no carregador:

Os nomes não indicam que todos os recursos estejam implementados, habilitados ou disponíveis para escrita. O OCPP 2.0.1 usa endereçamento por componentes e variáveis; o modelo do dispositivo e o caso de uso aplicável determinam como cada configuração funciona. Consulte as seções da Edition 4 sobre autorização e variáveis referenciadas.

Registre a capacidade da lista local, a confirmação de atualização, o tratamento de vencimentos, a persistência após reinicialização e o comportamento quando o armazenamento está cheio. Teste uma credencial conhecida que nunca tenha sido usada na estação e outra já autorizada nela. Isso ajuda a identificar de qual mecanismo local a implantação realmente depende.

Inclua a reconexão no teste. Confira como as transações offline chegam ao backend, como são conciliadas e o que acontece com uma sessão em andamento se o backend rejeitar sua credencial após a volta da conexão. Acorde com o proprietário do local a exposição operacional e financeira aceitável.

6. Escolha o modelo de segurança das credenciais de forma consciente

Pergunte se o leitor apenas lê um identificador ou realiza autenticação criptográfica com a credencial. Em um projeto baseado somente em UID, aceitar um identificador correspondente não demonstra a posse de um segredo criptográfico. Comprar um chip com recursos de segurança só agrega valor quando o leitor e a aplicação implantados usam esses recursos.

Quando a autenticação criptográfica do cartão for necessária, documente a aplicação compatível, a titularidade das chaves, o processo de provisionamento, o procedimento de substituição e as responsabilidades de migração. Não inclua segredos nos arquivos de entrega de UIDs. As orientações de segurança RFID do NIST, seção 5.3.1, descrevem a distinção entre identificadores e controles de autenticação. Trata-se de uma orientação fundamental publicada em 2007; use a documentação atual dos produtos para selecionar algoritmos e mecanismos compatíveis de gestão de chaves.

Proteja separadamente a conexão entre estação e backend. O Security Operations Guide atual da OCA, seções 4.2 e 4.4, descreve Security Profile 2 como TLS com Basic Authentication e Profile 3 como TLS com certificados do lado do cliente, além de tratar do armazenamento de credenciais. Confirme o perfil de transporte implantado, a validação de certificados e a gestão das credenciais da estação. Essas configurações protegem uma conexão diferente do enlace entre cartão e leitor.

7. Adicione autorização de roaming somente quando o serviço exigir

Uma instalação privada no local de trabalho pode precisar apenas do cadastro de credenciais da própria plataforma. O roaming acrescenta outra fronteira: o operador de pontos de recarga, ou CPO, precisa obter autorização do provedor de serviços de mobilidade elétrica correspondente, ou eMSP, por meio da integração compatível e do acordo comercial aplicável.

No OCPI 2.3.0, um registro de token contém os identificadores de país e de parte do provedor proprietário, um UID de token, tipo, validade e política de lista de permissão. A política ALLOWED_OFFLINE se refere à comunicação entre CPO e eMSP. Um carregador perder a conexão com o CSMS é uma interrupção separada. Teste ambas as fronteiras se as duas existirem.

O módulo Tokens também distingue um token válido de um autorizado em determinado local. A invalidação é propagada por um token atualizado com valid: false; excluir tokens por essa interface não é o mecanismo previsto. Confira o módulo Tokens oficial do OCPI 2.3.0 em relação à versão acordada com seu parceiro.

Para o piloto, identifique o emissor e a rede participante, estabeleça o caminho esperado de autorização e confira a sessão e o registro de recarga resultantes. Reutilizar o mesmo cartão físico em vários serviços ainda exige os cadastros, as permissões e os acordos apropriados.

8. Verifique o ciclo completo de acesso no comissionamento

Use uma matriz de testes com os resultados esperados escritos antes da execução. Execute-a em cada configuração distinta de hardware, firmware e backend e, em seguida, verifique por amostragem se o parque instalado corresponde à configuração aprovada.

Para cada execução, preserve horário, identificadores de estação e conector, firmware, referência do cartão de teste, configuração efetiva, resultado esperado, resultado real e registro relevante da transação. Oculte dados pessoais nas evidências compartilhadas fora da equipe operacional.

Quando um cartão for perdido, registre quando o aviso chegou e quando cada sistema conectado confirmou a alteração. Uma estação desconectada não consegue receber uma nova revogação imediatamente. A exposição prática depende do estado de autorização armazenado, das regras de vencimento e do comportamento na reconexão. Trate esse intervalo no procedimento operacional.

Diagnostique uma leitura malsucedida na fronteira correta

Colete uma tentativa malsucedida com seu carimbo de data e hora e a referência do cartão; depois, examine as evidências. Essas verificações delimitam a investigação sem presumir que toda rejeição tenha a mesma causa.

Exemplo de implantação em um pátio de frota

Considere um pátio fictício com 60 motoristas, 12 pontos de recarga e dois modelos de carregador. O operador quer atribuir o acesso a motoristas individuais, restringi-lo ao pátio e permitir que motoristas aprovados recarreguem durante uma interrupção do backend.

Comece com cinco credenciais de amostra. Em cada modelo de carregador, capture o identificador informado e acorde o mapeamento para o arquivo do fornecedor. Cadastre as amostras em uma conta piloto, atribua acesso ao pátio e confirme o centro de custo pretendido.

Se o equipamento tiver suporte a uma lista local gerenciada, pré-carregue as credenciais piloto e registre a versão confirmada. Mantenha as credenciais desconhecidas offline desabilitadas para essa política proposta. Desconecte a estação do CSMS em um teste controlado; depois, experimente um cartão pré-carregado, um desconhecido e um revogado com um estado local desatualizado documentado deliberadamente. Restabeleça a conexão e verifique a atualização e os registros de transações.

Conclua os testes de rejeição online, encerramento da sessão e faturamento nos dois modelos. Quando o piloto for aprovado, concilie o arquivo de produção de 60 cartões com o cadastro do backend, resolva exceções e distribua os cartões com um processo simples para comunicar perdas. Repita os testes relevantes de aceitação após mudanças significativas de firmware, modo do leitor ou plataforma.

Perguntas a resolver antes de encomendar

Os cartões RFID de recarga precisam ser programados?

Em um projeto que lê o UID existente do cartão, a configuração pode consistir em cadastrar esse valor e atribuir acesso na plataforma. Um projeto que usa uma aplicação protegida pode exigir personalização do cartão e configuração coordenada do leitor. Especifique o fluxo exato do leitor antes de contratar qualquer um desses serviços.

Um crachá de funcionário existente também pode liberar um carregador?

Isso pode ser possível quando o leitor é compatível com a tecnologia do crachá, o identificador necessário está disponível e é estável, e a plataforma permite o cadastro. Obtenha a aprovação do responsável pelo sistema de crachás e teste amostras reais. Como exemplo de cadastro específico de plataforma, a documentação da Easee sobre contas e chaves locais descreve escopos distintos de cadastro e alerta sobre identificadores que mudam.

Um cartão funcionará em todas as redes de recarga?

Verifique as redes pretendidas individualmente. Leitura física, cadastro da credencial, direitos da conta e qualquer acordo de roaming fazem parte dos critérios de aceitação. Teste a rede participante em vez de presumir a cobertura pela aparência do cartão.

O que o fornecedor de cartões deve receber?

Forneça os requisitos do leitor, o mapeamento de identificadores aprovado na amostra, o esquema de numeração visível, as especificações de material e impressão, a quantidade e o formato acordado de entrega dos dados. Inclua a pessoa responsável pela importação no backend e pela aceitação das amostras. Transfira segredos da aplicação por um processo seguro de provisionamento acordado separadamente quando o projeto exigir.

Prepare uma especificação de amostras para sua implantação

Reúna em uma única especificação o modelo e o firmware do carregador, o nome do backend e a versão do protocolo, o modo de credencial necessário, a representação confirmada do identificador e a política offline pretendida. Use o laboratório de credenciais da ChargeRFID para revisar a entrega dos dados e solicite amostras prontas para seu piloto. Aprove a credencial física e todo o seu fluxo de acesso em conjunto antes de liberar o pedido de produção.