Movilidad eléctrica en España: una arquitectura distribuida
Si operas una red de recarga, construyes un eMSP o tomas decisiones de plataforma como CTO, la movilidad eléctrica se parece menos a un proyecto de “IoT con pagos” y más a un sistema distribuido con múltiples dominios: identidad, roaming, telemetría, control remoto, tarificación, liquidación B2B y seguridad extremo a extremo. La experiencia del conductor (encontrar, iniciar, cargar, pagar) depende de que varias empresas y protocolos encajen con fiabilidad, y de que tu software gestione estados, errores y reconciliaciones sin inconsistencias.
En este artículo organizamos el ecosistema desde el punto de vista de ingeniería de software: quiénes son los actores, qué responsabilidades técnicas tiene cada uno, y qué protocolos se usan en cada “capa” (vehículo–cargador, cargador–backend, y CPO–eMSP con o sin hub). También incluimos una panorámica práctica de conectores y potencias, centrada en el contexto europeo/español, para alinear expectativas técnicas y de producto.
Actores del ecosistema y responsabilidades de software
Antes de hablar de protocolos conviene fijar roles, porque gran parte de los problemas de integración nacen de suposiciones equivocadas: quién “posee” un dato, quién factura a quién, y quién opera el activo físico. Un mismo grupo empresarial puede asumir varios roles, pero los contratos técnicos (APIs, SLA, modelos de datos) suelen seguir esta separación.
- CPO (Charge Point Operator): opera la infraestructura de recarga (cargadores/EVSE), su conectividad, el mantenimiento, el control remoto, la monitorización y la emisión de CDRs (Charge Detail Records) para liquidación B2B.
- eMSP (eMobility Service Provider): provee el servicio al conductor (app, contrato, soporte), gestiona identidad (RFID, app, certificados en Plug&Charge), aplica pricing final al usuario y concilia sesiones/consumos con CPOs o hubs.
- Hub (roaming hub): conecta múltiples CPOs con múltiples eMSPs para reducir integraciones bilaterales; enruta y normaliza intercambios (localizaciones, tokens, sesiones, CDRs, tarifas) según el protocolo de roaming.
- DSO (operador de distribución): gestiona y distribuye energía; participa en escenarios de limitación/optimización de potencia y coordinación con redes de recarga (especialmente en smart charging).
- SCSP (Smart Charging Service Provider): capa de servicios para optimización (carga inteligente), que puede operar como tercero y hablar con CPO/DSO para ajustar potencia y perfiles.
- NAP (National Access Point): base de datos (habitualmente pública) con puntos de recarga, para acceso/consulta a nivel país/entorno regulatorio.
- NSP (Navigation Service Provider): servicios de navegación/localización que ayudan a descubrir puntos de recarga y sus características.
Un matiz importante para producto y revenue: el CPO suele facturar al eMSP por las sesiones, y el eMSP cobra al conductor; el CPO no necesariamente define el precio final al usuario. Esto afecta a cómo modelas tarifas, impuestos, promociones y disputas en tu backend.
Por qué los protocolos importan a operaciones y a software
Los protocolos en recarga de VE no son un detalle de integración: son la base de interoperabilidad, seguridad y calidad de servicio. Sin estándares, cada conexión se convierte en un proyecto a medida que multiplica costes, introduce ambigüedad en estados y complica auditoría y facturación.
- Interoperabilidad: permite que distintos fabricantes/operadores trabajen juntos sin lock-in técnico.
- Intercambio de datos: estructura credenciales, tarifas, sesiones, CDRs y eventos de estado para que sean coherentes entre sistemas.
- Supervisión y operación: habilita monitorización y control remoto, clave para disponibilidad en campo y para soporte.
- Carga inteligente: posibilita optimización en función de red/tarifas/capacidad, reduciendo picos y mejorando eficiencia.
- Plug & Charge: automatiza autenticación/autorización cuando el coche se conecta (si el stack lo soporta).
Arquitectura por capas: quién habla con quién
Una forma útil (y muy “operable”) de entender el ecosistema es separarlo en capas de comunicación. Cada capa resuelve problemas distintos y, por tanto, usa protocolos distintos: si intentas hacer “roaming” con un protocolo pensado para telemetría, terminarás con integraciones frágiles y costosas de mantener.
Capa 1 — Vehículo ↔ Cargador (EV–EVSE)
En el borde se negocian aspectos críticos de la sesión (autenticación avanzada, parámetros de carga y, en casos modernos, Plug & Charge). Aquí destaca ISO 15118 como estándar de comunicación entre vehículo eléctrico y la infraestructura de carga, y se asocia con Plug & Charge, smart charging y soporte para flujos tipo V2G cuando el sistema lo permite.
- Implicaciones software: ciclo de vida de certificados, gestión de identidad basada en PKI, negociación de parámetros, compatibilidad entre versiones y “quirks” de implementación por OEM.
- Implicaciones operativas: cuando falla Plug & Charge, necesitas estrategias de fallback (RFID/app), y observabilidad para distinguir problema de vehículo vs cargador vs backend.
Capa 2 — Cargador ↔ Sistema central del CPO (operación y control)
Esta capa es la “columna vertebral” de un CPO: estados, heartbeats, comandos remotos, disponibilidad, incidencias y métricas. El estándar más habitual aquí es OCPP, un protocolo abierto entre la estación de recarga y el sistema central de gestión, ampliamente adoptado para interoperabilidad entre fabricantes, operadores y software.
- OCPP 1.6: muy extendido; se usa para comunicación estación–sistema central y puede coexistir con extensiones asociadas a ISO 15118 (a menudo referido como 1.6+).
- OCPP 2.0.1: versión operativa lanzada en 2020; añade funciones, mejora seguridad y rendimiento, y es totalmente compatible con ISO 15118 (Plug & Charge).
- IEC 63110: norma internacional enfocada en gestión de infraestructura de carga/descarga, con énfasis en interoperabilidad y procesos de negocio.
Desde el punto de vista de diseño de plataforma, esta capa exige idempotencia (reintentos y reconexiones), consistencia de estados (evitar “sesiones fantasma”), y un modelo de eventos que permita observabilidad real (correlación por IDs, timestamps confiables y auditoría). También es donde más se nota la diferencia entre un backend “funciona en demos” y uno que sostiene una operación 24/7.
Capa 3 — CPO ↔ eMSP (roaming e interoperabilidad, con o sin hub)
El roaming hace posible que un conductor use cargadores de terceros con su app/tarjeta habitual. Aquí se intercambian localizaciones, tokens/credenciales, sesiones y CDRs, y se habilitan comandos como remote start/stop, reservas y desbloqueo del conector, según acuerdos.
OCPI (Open Charge Point Interface)
OCPI es un protocolo de comunicación entre CPO y eMSP que facilita comunicación directa, aunque también puede operar a través de un hub conectando múltiples CPOs y eMSPs.
- Módulos típicos (en la práctica): Locations, Tokens, Sessions, CDRs, Tariffs, Commands, entre otros.
- Modelo mental útil: “Locations y Tariffs los publica el CPO; Tokens los aporta el eMSP; Sessions y CDRs suelen ‘vivir’ del lado CPO y se comparten para conciliación”.
OICP (Open InterCharge Protocol)
OICP se orienta a interoperabilidad a través de un enfoque centralizado: a diferencia de OCPI (que permite comunicación directa), OICP canaliza las comunicaciones a través de una única plataforma hub como punto central.
OCHP y eMIP
OCHP conecta backends con una “cámara de compensación” (clearing house) para simplificar comunicación y liquidación; eMIP es un protocolo abierto para facilitar interacciones entre CPO y eMSP, con una arquitectura que incluye un hub (IoP) y servidores CPO/eMSP en el intercambio.
Flujos end-to-end (lo que tu plataforma debe soportar)
Los equipos de operaciones y desarrollo se alinean mejor cuando piensan en “journeys” concretos. A continuación, cuatro flujos típicos con los puntos donde suelen aparecer incidencias y deuda técnica, especialmente en roaming.
1) Descubrimiento: del mapa a un EVSE real
- El eMSP consume localizaciones y metadatos del CPO (directo o vía hub) para mostrar puntos y conectores disponibles.
- Reto software: datos incompletos o desactualizados (estado, potencia, conectores), y normalización de modelos entre múltiples CPOs.
2) Autorización e inicio: identidad, tokens y fallback
- El conductor se autentica con RFID/app o con Plug & Charge mediante certificado del vehículo, y el sistema valida antes de permitir el inicio de la sesión.
- El eMSP puede solicitar remote start/stop, reservas, cancelaciones o desbloqueo de conector (según capacidad del operador y acuerdos).
- Reto software: estados intermedios (authorized pero no started), timeouts, reintentos y reconciliación cuando el cargador se queda sin conectividad.
3) Durante la sesión: telemetría, control de potencia y consistencia
- El CPO notifica inicio, actualizaciones de progreso y fin de sesión; el eMSP lo usa para UX (tiempo, kWh, coste estimado) y soporte.
- Reto software: idempotencia de eventos, relojes desincronizados, duplicados y “sesiones huérfanas” que afectan facturación y disputas.
4) Cierre, CDR y liquidación B2B
- Tras finalizar, el CPO envía el detalle de cobro (CDR) para liquidación con el eMSP.
- Reto software: conciliación de tarifas (Tariffs), cambios de precio, impuestos, y reglas de redondeo; además de procesos de disputa y auditoría.
Carga inteligente y gestión de energía (cuando la red manda)
A medida que crece la potencia instalada, la coordinación con la red se vuelve una necesidad: no solo por coste, también por capacidad física y estabilidad. En este contexto aparece el smart charging, orientado a optimizar la carga mediante gestión de distribución de energía y comunicación entre DSO y CPO para uso eficiente, especialmente en horas pico.
- Implicación software: necesitas un motor de políticas (power caps, horarios, prioridades), telemetría fiable y capacidad de aplicar perfiles de carga en tiempo real.
- Implicación operativa: observabilidad por sitio (transformador, cuadro, cargadores), y herramientas para explicar “por qué cargó más lento” sin culpar siempre al coche o al usuario.
Conectores y potencias: lo esencial para España (y lo que tu modelo de datos debe reflejar)
En Europa —y por tanto en España— el día a día gira alrededor de Tipo 2 para AC y CCS2 para DC, pero tu software no puede asumir monocultura: roaming, flotas y turismo internacional introducen variaciones. La clave es modelar con precisión conector, modo (AC/DC), potencia máxima teórica, potencia disponible dinámica y restricciones del sitio.
Conectores AC (carga lenta/semirrápida)
- Tipo 2 (IEC 62196 Tipo 2): estándar habitual en Europa para carga AC.
- SAE J1772 / Tipo 1: estándar norteamericano, relevante en determinados vehículos/importaciones; soporta AC monofásica con potencias variables según instalación.
Conectores DC (carga rápida)
- CCS (CCS1/CCS2): “combinado” porque añade pines DC a conectores AC Tipo 1 y Tipo 2, formando CCS1 y CCS2; puede suministrar hasta 350 kW, y CCS2 es el predominante en Europa.
- CHAdeMO: estándar de carga rápida con presencia histórica en Asia (y parque instalado residual en Europa según zonas y antigüedad).
Potencia: de “máxima” a “entregada” (lo que hay que explicar al usuario)
En operación, la potencia anunciada es solo el techo: la potencia real depende del coche (curva de carga, temperatura, SOC), del cargador, del reparto en el emplazamiento y de límites de red. Si tu plataforma no diferencia entre “capacidad del EVSE” y “potencia entregada por sesión”, terminarás con métricas engañosas, reclamaciones y soporte ineficiente.
- Recomendación de modelado: guarda potencia nominal del conector/EVSE, potencia asignada dinámicamente y energía medida (kWh) con timestamps; correlaciona con la sesión y con eventos de estado.
- Recomendación de UX/ops: expón causas probables cuando la potencia cae (power sharing, limitación del sitio, smart charging, límites del vehículo) para reducir fricción y tickets.