Operações de frotas

Cartões RFID de carregamento para frotas: guia para operações comerciais com veículos elétricos

Como os cartões RFID de carregamento para frotas apoiam a afetação de veículos, a integração OCPP, os registos com relevância fiscal, a autorização em vários depósitos e a emissão para condutores.

Detalhes do artigo

Publicado
2 de maio de 2026
Atualizado
10 de julho de 2026
Tempo de leitura
8 min de leitura
Editor
ChargeRFID
Voltar aos recursos

Por ChargeRFID

Método de revisão: Verificámos este guia com base nas referências primárias regulamentares, de protocolo e de fabricantes indicadas abaixo. As recomendações de produto refletem a perspetiva de fabrico da ChargeRFID e devem ser validadas com o seu leitor, carregador e backend.

Cartões RFID de carregamento para frotas: guia para operações comerciais com veículos elétricos

Gerir uma frota comercial de veículos elétricos altera a economia do carregamento. Em vez de um condutor a pagar com um cartão de crédito pessoal numa estação de serviço, há 50, 500 ou 5000 condutores a carregar em depósitos, postos públicos e carregadores domésticos — e cada sessão gera dados de custo, de kWh e com relevância fiscal que têm de ser integrados corretamente no software de gestão de frotas. Os cartões RFID de carregamento para frotas são a forma de captar esses dados na origem.

Este guia explica o que distingue um cartão RFID de carregamento para frotas de um cartão para consumidores, como funciona a cadeia de autenticação e de relatórios e o que especificar ao emitir cartões num programa comercial de veículos elétricos.

O que distingue um cartão RFID de carregamento para frotas

Um cartão de carregamento apresenta um token. Se esse token representa um condutor, um veículo, um depósito, um centro de custos ou um contrato, é algo determinado pelos backends da frota e de carregamento. Um único cartão não identifica, por si só, todas essas entidades em simultâneo.

O cartão pode utilizar uma credencial de 13.56 MHz com autenticação AES ou outra tecnologia compatível com o leitor. A distinção importante é a forma como o respetivo identificador ou aplicação protegida é preparado e mapeado nos backends:

•Registo de kWh por veículo — o UID do cartão é associado a um veículo específico no sistema de gestão de frotas, para que cada sessão de carregamento possa ser imputada a um veículo.
•Atribuição ao condutor — em conjunto com a telemática do veículo, o cartão permite à frota imputar as despesas com energia ao condutor afeto a esse veículo nesse dia.
•Autorização por depósito — os grupos no backend podem restringir os tokens por depósito; as chaves criptográficas só podem acrescentar uma camada adicional quando os cartões e os leitores utilizam uma aplicação protegida.
•Registos com relevância fiscal — no Reino Unido, o tratamento depende da propriedade do veículo, do local de carregamento, da utilização profissional ou privada e da forma como o reembolso é calculado. Os registos das sessões apoiam o cálculo, mas não o tornam, por si só, específico do programa.

Como funciona a autenticação RFID de frotas em postos OCPP

O fluxo de autorização e de transação depende da versão do OCPP. Um percurso típico em OCPP 1.6 é o seguinte:

Quando um condutor aproxima um cartão de frota do leitor num depósito ou num posto público:

1.O posto extrai o UID e envia `Authorize.req` ao sistema central (Central System).
2.O sistema central compara o UID com a lista de identificadores autorizados da frota (frequentemente filtrada por depósito, grupo de condutores ou grupo de veículos).
3.Em caso de aprovação, o posto envia `StartTransaction` com campos que incluem o conector, o idTag, o carimbo temporal e o valor inicial do contador.
4.No fim da sessão, `StopTransaction` envia o identificador da transação, o carimbo temporal, o valor final do contador e dados opcionais da transação. A duração, a energia e um CDR de faturação são calculados ou compilados por sistemas a jusante; não se trata de um CDR incorporado na mensagem OCPP 1.6.
5.O sistema de gestão de carregamento pode enriquecer a sessão e enviar os registos para o backend de relatórios da frota. O OCPP 2.x utiliza o modelo `TransactionEvent`, que é diferente, em vez do par de mensagens de início/fim do OCPP 1.6.

Nas frotas que combinam carregamento em depósito e em postos públicos, o roaming OCPI encaminha os CDR dos CPO externos, através do MSP da frota, para o mesmo circuito de relatórios.

Modelos de cartão por veículo e por condutor

A maioria das frotas escolhe entre duas arquiteturas:

Os cartões por veículo ficam com o veículo (no porta-luvas ou presos a um porta-chaves). Vantagens: experiência simples para o condutor e reatribuição fácil quando os condutores trocam de veículo. Desvantagens: são roubados juntamente com o veículo e não permitem isolar o comportamento de cada condutor.

Os cartões por condutor acompanham o condutor de veículo para veículo. Vantagens: imputação direta ao nível do condutor. Desvantagens: a imputação exata por veículo e por quilometragem continua a exigir dados de atribuição ou de telemática, e o tratamento fiscal tem de seguir as regras aplicáveis da HMRC, e não apenas o modelo de cartão.

Muitas frotas de grande dimensão emitem ambos — um cartão por condutor para imputação de custos e um porta-chaves por veículo para redundância e facilidade de acesso.

Gestão de chaves em vários depósitos

Nas frotas com vários depósitos, a autorização pode ser aplicada no backend por grupo de tokens, veículo, condutor ou local. A credencial de 13.56 MHz com autenticação AES também suporta chaves de aplicação diversificadas quando os leitores instalados autenticam uma aplicação protegida, em vez de lerem apenas o UID público.

Com uma aplicação protegida corretamente concebida, domínios de chaves separados podem limitar o alcance de um comprometimento de chaves. A rotação dessas chaves continua, no entanto, a exigir um processo documentado que abranja leitores, cartões, módulos seguros e backend; num esquema de autorização baseado no UID público, a revogação faz-se, em alternativa, no backend, por token individual ou por grupo.

Evite uma única chave de aplicação partilhada por toda a frota, mas não acrescente chaves aos cartões que os leitores de carregamento e o backend nunca autenticam. Adeque o controlo à arquitetura de autorização real.

Relatórios: do CDR OCPP a resultados prontos para a HMRC

O cartão é apenas o ponto de entrada. É a cadeia de relatórios que torna um programa de frota financeiramente viável.

Um fluxo de trabalho típico de uma frota no Reino Unido:

1.O condutor aproxima o cartão → o posto autoriza → a sessão decorre → o CDR é registado.
2.O CDR é enriquecido com metadados do condutor, do veículo e do depósito provenientes do sistema de gestão de frotas.
3.O custo da energia é calculado com base na tarifa contratada (frequentemente por períodos horários ou com repercussão direta de custos).
4.Os dados de quilometragem e de local de carregamento são combinados, quando necessário, para aplicar o tratamento de reembolso ou de benefício da HMRC pertinente.
5.Os resultados revistos podem então apoiar os processos salariais, de despesas ou fiscais adequados à propriedade do veículo e ao caso de utilização.

A cadeia que vai do cartão ao relatório deve ser auditável de ponta a ponta. Esse registo de auditoria provém normalmente dos valores de contagem do posto, dos eventos OCPP, dos registos de sessões e de CDR do CPO/eMSP, dos dados tarifários, dos mapeamentos de tokens e dos metadados da frota. As funcionalidades de MAC de transação da credencial de 13.56 MHz com autenticação AES não criam nem validam automaticamente o CDR de carregamento do backend, sobretudo quando um carregador lê apenas o UID do cartão.

Roaming para carregamento misto em depósito e em postos públicos

A maioria das frotas comerciais não consegue funcionar apenas com carregamento em depósito. Os condutores de longo curso, os operadores de última milha com rotas variáveis e qualquer frota com políticas de carregamento doméstico precisam de acesso a redes públicas com o mesmo cartão.

É aqui que a publicação de tokens e os acordos de roaming ativos se tornam importantes. Um cartão de frota emitido por um eMSP pode funcionar nos CPO contratados a que se acede através de uma plataforma de interligação (hub) ou de uma ligação OCPI/OICP direta. A cobertura deve ser aferida a partir da lista atual de redes contratadas do eMSP; o número total de pontos ligados a uma plataforma não garante que um determinado cartão seja aceite em todo o lado.

Os CDR regressam ao MSP da frota, são novamente tarifados se o contrato utilizar um modelo com margem e seguem para o mesmo circuito de relatórios que as sessões em depósito.

O que especificar ao emitir cartões RFID de carregamento para frotas

Um exemplo de lista de verificação para aprovisionamento:

•Chip e aplicação: tecnologia compatível com o leitor; utilize chaves da credencial de 13.56 MHz com autenticação AES apenas quando o leitor autenticar a aplicação protegida
•Material: PVC reciclado (o mais comum) ou madeira FSC para programas orientados por critérios ESG
•Formato: cartões ISO 7810 ID-1 e porta-chaves para fixação no veículo
•Impressão: a cores, com identificação do veículo/condutor, logótipo da frota e gravação a laser antiadulteração
•Codificação: UID pré-codificado, idTag alinhado com o formato do MSP e chave diversificada específica de cada depósito
•Roaming: publicação dos tokens e acordos eMSP–CPO ativos para as redes necessárias
•Política de reemissão: fluxo de trabalho para perda, revogação, substituição e sincronização, com base nos dados do projeto-piloto
•Condições comerciais: MOQ, preço, prazo de entrega e condições de substituição em vigor, num orçamento escrito do fornecedor

Erros comuns em programas de cartões para frotas

•Emitir cartões antes de a integração com o MSP estar ativa — os condutores aproximam o cartão e são recusados porque o idTag ainda não está registado.
•Uma única chave de aplicação partilhada por toda a frota — alarga desnecessariamente o âmbito de um eventual comprometimento quando as aplicações protegidas estão efetivamente em uso.
•Ausência de processo de reemissão — deixa sem gestão os cartões perdidos, os tokens de substituição e a sincronização com o backend.
•Pontos cegos no carregamento público — partir do princípio de que «basta instalar mais carregadores no depósito», em vez de prever o roaming desde o primeiro dia.
•Formato de UID incompatível — diferentes MSP esperam diferentes formatos de idTag (4 bytes, 7 bytes, hexadecimal vs. decimal); alinhe este ponto antes de codificar 5000 cartões.

Próximos passos

Um programa de cartões RFID de carregamento para frotas assenta numa especificação com quatro eixos: segurança do chip, formato de codificação, alcance de roaming e integração com os relatórios. Acerte nestes pontos e os cartões tornam-se uma infraestrutura invisível — os condutores aproximam o cartão, a energia flui e os dados chegam corretamente à contabilidade da frota.

Consulte os nossos cartões de carregamento de VE em PVC reciclado e madeira FSC ou saiba como criámos programas de cartões para frotas com um programa de carregamento de VE selecionado e um programa de carregamento para frotas selecionado. Fale connosco sobre o programa de carregamento da sua frota — ajudamos a especificar o cartão certo e a alinhá-lo com o seu MSP.

Os nomes de empresas, redes e produtos referidos neste artigo são marcas comerciais dos respetivos proprietários. São utilizados de forma descritiva para identificar os sistemas com os quais os nossos cartões interoperam. A ChargeRFID é um fabricante independente e este artigo não afirma qualquer afiliação, parceria ou aprovação.

Fontes primárias

Referências oficiais utilizadas para rever as afirmações regulamentares, de protocolo e ao nível do chip apresentadas neste guia.

Partilhar:

Próximo passo

Transforme a pesquisa numa especificação de cartão.

Indique o contexto do leitor, do chip, dos dados ou da implementação e identificaremos as decisões necessárias para as amostras e a produção.