Operaciones de flotas

Tarjetas RFID para la recarga de flotas: guía para operaciones comerciales de VE

Cómo funcionan las tarjetas RFID de recarga para flotas en operaciones comerciales de VE: seguimiento de kWh por vehículo, integración con OCPP, informes específicos del programa, gestión de claves en múltiples depósitos y qué especificar al emitir tarjetas a los conductores.

Datos del artículo

Publicado
2 de mayo de 2026
Tiempo de lectura
8 min de lectura
Editor
ChargeRFID
Volver a Recursos

Por ChargeRFID

Método de revisión: Hemos contrastado esta guía con las fuentes primarias sobre normativa y protocolos y las fuentes primarias de los fabricantes que se enumeran a continuación. Las recomendaciones de productos reflejan la perspectiva de ChargeRFID como fabricante y deben validarse con su lector, su estación de carga y su backend.

Tarjetas RFID para la recarga de flotas: guía para operaciones comerciales de VE

Gestionar una flota comercial de vehículos eléctricos cambia la economía de la recarga. En lugar de que un único conductor pase su tarjeta de crédito personal en una estación de servicio, usted tiene a 50, 500 o 5000 conductores recargando en cocheras, estaciones públicas y cargadores domésticos. Cada sesión genera costes, kWh y datos de relevancia fiscal que deben integrarse de forma limpia en el software de gestión de flotas. Las tarjetas RFID de recarga para flotas permiten capturar esos datos directamente en el origen.

Esta guía explica qué diferencia a una tarjeta RFID de recarga para flotas de una tarjeta para particulares, cómo funciona la cadena de autenticación e informes y qué especificaciones debe definir al emitir tarjetas para un programa comercial de vehículos eléctricos.

Qué diferencia a una tarjeta RFID de recarga para flotas

Una tarjeta de recarga presenta un token. Los sistemas de gestión de la flota y de la recarga determinan si ese token representa a un conductor, un vehículo, una cochera, un centro de costes o un contrato. Una tarjeta no identifica de forma inherente a todas esas entidades a la vez.

La tarjeta puede utilizar una tecnología de credenciales de 13,56 MHz con autenticación AES u otra tecnología compatible con el lector. La diferencia importante radica en cómo se aprovisiona su identificador o su aplicación protegida y cómo se establecen sus correspondencias en los sistemas de gestión:

•Seguimiento de kWh por vehículo: el UID de la tarjeta se asocia a un vehículo específico en el sistema de gestión de flotas, de modo que cada sesión de recarga se puede asignar a un vehículo concreto.
•Atribución al conductor: combinada con la telemática del vehículo, la tarjeta permite a la flota atribuir el gasto energético al conductor asignado a ese vehículo ese día.
•Autorización por cochera: los grupos definidos en el sistema de gestión pueden restringir los tokens por cochera; las claves criptográficas solo pueden añadir otra capa cuando las tarjetas y los lectores utilizan una aplicación protegida.
•Registros de relevancia fiscal: en el Reino Unido, el tratamiento depende de la titularidad del vehículo, el lugar de recarga, el uso profesional o privado y el método de cálculo del reembolso. Los registros de las sesiones ayudan a realizar el cálculo, pero no bastan por sí solos para adaptarlo a las particularidades del programa.

Cómo funciona la autenticación RFID de flotas en estaciones OCPP

El flujo de autorización y transacciones depende de la versión de OCPP. Un flujo típico de OCPP 1.6 es el siguiente:

Cuando un conductor acerca una tarjeta de flota a una estación de recarga en una cochera o en la red pública:

1.La estación extrae el UID y envía Authorize.req al Sistema Central.
2.El Sistema Central contrasta el UID con la lista de autorizados de la flota, a menudo filtrada por cochera, grupo de conductores o grupo de vehículos.
3.Tras la aprobación, la estación envía StartTransaction con campos que incluyen el conector, el idTag, la marca de tiempo y el valor inicial del contador.
4.Al finalizar la sesión, StopTransaction envía el identificador de la transacción, la marca de tiempo, el valor final del contador y datos opcionales de la transacción. La duración, la energía y el CDR para facturación se calculan o se elaboran en los sistemas posteriores; no constituyen un CDR integrado en el mensaje de OCPP 1.6.
5.El sistema de gestión de recarga puede enriquecer la sesión y enviar los registros al sistema de informes de la flota. OCPP 2.x utiliza un modelo diferente, TransactionEvent, en lugar del par de mensajes de inicio y fin de OCPP 1.6.

Para las flotas que combinan recarga en cocheras y en la red pública, la itinerancia mediante OCPI incorpora los CDR de los CPO externos al mismo flujo de informes a través del MSP de la flota.

Modelos de tarjetas: por vehículo frente a por conductor

La mayoría de las flotas eligen entre dos arquitecturas:

Tarjetas por vehículo: permanecen en el vehículo, en la guantera o unidas a un llavero. Ventajas: experiencia sencilla para el conductor y reasignación fácil cuando los conductores cambian de vehículo. Desventajas: pueden ser robadas junto con el vehículo y no permiten aislar el comportamiento de cada conductor.

Tarjetas por conductor: acompañan al conductor cuando cambia de vehículo. Ventajas: atribución directa al conductor. Desventajas: la asignación precisa por vehículo y la atribución de los kilómetros recorridos siguen requiriendo datos de asignación o de telemática, y el tratamiento fiscal debe seguir las normas de HMRC aplicables, sin depender únicamente del modelo de tarjeta.

Muchas flotas de gran tamaño emiten ambas opciones: una tarjeta por conductor para la asignación de costes y un llavero por vehículo como respaldo y para facilitar el acceso.

Gestión de claves en múltiples cocheras

Para las flotas que operan en múltiples cocheras, la autorización puede aplicarse en el sistema de gestión por grupo de tokens, vehículo, conductor o emplazamiento. Las credenciales de 13,56 MHz con autenticación AES también admiten claves de aplicación diversificadas cuando los lectores instalados autentican una aplicación protegida en lugar de leer únicamente el UID público.

Con una aplicación protegida correctamente diseñada, los dominios de claves separados pueden limitar el alcance de una vulneración de claves. La rotación de esas claves sigue requiriendo un proceso documentado que abarque los lectores, las tarjetas, los módulos seguros y el sistema de gestión; en cambio, un esquema de autorización basado en el UID público revoca tokens individuales o agrupados en el sistema de gestión.

Evite utilizar una única clave de aplicación compartida para toda la flota, pero no añada claves a las tarjetas si los lectores de recarga y el sistema de gestión nunca las autentican. Adapte la medida de control a la arquitectura real de autorización.

Informes: del CDR de OCPP a un resultado preparado para HMRC

La tarjeta es solo el punto de entrada. La cadena de informes es lo que hace que un programa de flotas sea viable desde el punto de vista financiero.

Flujo de trabajo típico de una flota del Reino Unido:

1.El conductor acerca la tarjeta → la estación autoriza la operación → se realiza la sesión → se registra el CDR.
2.El CDR se enriquece con metadatos del conductor, el vehículo y la cochera procedentes del sistema de gestión de flotas.
3.El coste de la energía se calcula utilizando la tarifa contratada, a menudo por franjas horarias o mediante la repercusión de costes.
4.Cuando es necesario, se combinan los datos de kilometraje y del lugar de recarga para aplicar el tratamiento correspondiente de HMRC a los reembolsos o las retribuciones en especie.
5.Una vez revisados, los resultados pueden servir de apoyo a los procesos de nóminas, gastos o gestión fiscal que correspondan según la titularidad del vehículo y el caso de uso.

La cadena que va desde la tarjeta hasta el informe debería ser auditable de extremo a extremo. Esa trazabilidad suele proceder de las lecturas de los contadores de las estaciones, los eventos OCPP, los registros de sesiones y CDR de los CPO/eMSP, los datos de tarifas, las correspondencias de tokens y los metadatos de la flota. Las funciones de MAC de transacción de las credenciales de 13,56 MHz con autenticación AES no crean ni validan automáticamente el CDR de recarga del sistema de gestión, especialmente cuando un cargador solo lee el UID de la tarjeta.

Itinerancia para recarga mixta en cocheras y red pública

La mayoría de las flotas comerciales no pueden operar limitándose exclusivamente a la recarga en cocheras. Los conductores de larga distancia, los operadores de última milla con rutas variables y cualquier flota con políticas de recarga en el hogar necesitan acceder a la red pública con la misma tarjeta.

Aquí es donde importan la publicación de tokens y los acuerdos de itinerancia vigentes. Una tarjeta de flota emitida por un eMSP puede funcionar en los CPO con los que existen acuerdos y a los que se accede mediante una plataforma de interconexión o una conexión directa OCPI/OICP. La cobertura debe consultarse en la lista actual de redes contratadas del eMSP; el número total de puntos conectados a una plataforma no garantiza que una tarjeta concreta sea aceptada en todos ellos.

Los CDR se envían al MSP de la flota, se recalculan los precios si el contrato utiliza un modelo de margen comercial y se integran en el mismo flujo de informes que las sesiones de las cocheras.

Qué especificar al emitir tarjetas RFID de recarga para flotas

Un ejemplo de lista de requisitos de compra es:

•Chip y aplicación: tecnología compatible con el lector; utilice claves de credenciales de 13,56 MHz con autenticación AES únicamente cuando el lector autentique la aplicación protegida.
•Material: PVC reciclado, el más común, o madera con certificación FSC para programas orientados a objetivos ESG.
•Formato: tarjetas ISO 7810 ID-1 y llaveros para fijar al vehículo.
•Impresión: a todo color con el ID del vehículo/conductor, logotipo de la flota y grabado láser antimanipulación.
•Codificación: UID precodificado, idTag alineado con el formato del MSP y clave diversificada específica para cada cochera.
•Itinerancia: publicación de tokens y acuerdos eMSP–CPO vigentes para las redes necesarias.
•Política de reemisión: procedimiento para pérdidas, revocaciones, sustituciones y sincronización basado en los datos de la prueba piloto.
•Condiciones comerciales: cantidad mínima de pedido (MOQ), precio, plazo de entrega y condiciones de sustitución vigentes, recogidos en una oferta escrita del proveedor.

Errores comunes en los programas de tarjetas para flotas

•Emitir tarjetas antes de que la integración con el MSP esté activa: los conductores acercan la tarjeta al lector y el sistema la rechaza porque el idTag aún no está registrado.
•Una sola clave de aplicación compartida para toda la flota: amplía innecesariamente el alcance de una vulneración cuando se utilizan aplicaciones protegidas.
•No disponer de un proceso de reemisión: deja sin gestionar las tarjetas perdidas, los tokens de sustitución y la sincronización con el sistema de gestión.
•Ignorar la recarga pública: asumir que "simplemente instalaremos más cargadores en la cochera" en lugar de diseñar la itinerancia desde el primer día.
•Formatos de UID incompatibles: los diferentes MSP requieren formatos de idTag distintos, de 4 bytes o 7 bytes, en hexadecimal o decimal; asegúrese de alinear este aspecto antes de codificar 5000 tarjetas.

Próximos pasos

Un programa de tarjetas RFID de recarga para flotas se define mediante cuatro ejes: la seguridad del chip, el formato de codificación, el alcance de la itinerancia y la integración de los informes. Si define correctamente estos elementos, las tarjetas se convertirán en una infraestructura invisible: los conductores las acercan al lector, la energía fluye y los datos se registran de forma limpia en la contabilidad de la flota.

Explore nuestras tarjetas de recarga de VE de PVC reciclado y madera FSC o descubra cómo desarrollamos programas de tarjetas para flotas con un programa de recarga de VE seleccionado y un programa de recarga de flotas seleccionado. Póngase en contacto con nosotros para hablar sobre el programa de recarga de su flota: le ayudaremos a especificar la tarjeta adecuada y a alinearla con su MSP.

Los nombres de empresas, redes y productos mencionados en este artículo son marcas de sus respectivos titulares. Se emplean de forma descriptiva para identificar los sistemas con los que nuestras tarjetas son compatibles. ChargeRFID es un fabricante independiente y este artículo no afirma ninguna afiliación, asociación ni respaldo.

Fuentes primarias

Referencias oficiales utilizadas para revisar las afirmaciones de esta guía sobre normativa, protocolos y características de los chips.

Compartir:

Siguiente paso

Convierta la información analizada en una especificación de tarjeta.

Comparta el contexto del lector, el chip, los datos o el despliegue y le indicaremos qué decisiones hay que tomar para las muestras y la producción.