Elegir entre sistemas de gestión de carga de vehículos eléctricos en la nube o en las instalaciones no es simplemente una decisión de alojamiento de TI. Determina quién opera la infraestructura, dónde residen los datos de carga y pago, con qué rapidez puede escalar la red, cómo se implementan las actualizaciones y qué equipo se encarga de la seguridad, las copias de seguridad, la monitorización y la recuperación ante desastres.
Cloud CPMS suele ser la opción práctica para redes de carga distribuidas y en crecimiento. que valoran una implementación más rápida, operaciones centralizadas, capacidad elástica y mantenimiento de la plataforma gestionado por el proveedor. La implementación local se adapta a las organizaciones con requisitos estrictos de residencia de datos, aislamiento de red, control de infraestructura o integración interna.—siempre que cuenten con el personal y los procesos necesarios para operar el entorno completo. Los modelos de nube privada e híbridos se sitúan entre estas dos opciones.
La respuesta correcta depende de su red de cargadores, países objetivo, flujos de usuarios y pagos, modelo de riesgo, integraciones, capacidad de TI interna y plan de crecimiento a cinco años. Si necesita definir primero la pila técnica más amplia, lea la de TrendPower. Guía de arquitectura del sistema de gestión de carga de vehículos eléctricos.
¿Qué significan realmente Nube, Nube privada, En las instalaciones y Híbrido?
Los documentos de adquisición suelen utilizar estas etiquetas de forma imprecisa. Antes de comparar las propuestas, solicite a cada proveedor que dibuje la arquitectura propuesta y asigne la responsabilidad de cada capa de infraestructura y software.
CPMS en la nube pública o SaaS
La aplicación se ejecuta en una infraestructura en la nube y se accede a ella de forma segura a través de internet. El proveedor suele gestionar la aplicación y gran parte del funcionamiento de la plataforma, mientras que el comprador gestiona los usuarios, la configuración empresarial, la gobernanza de datos, las integraciones y sus propias responsabilidades de seguridad.
Nube privada
El entorno está dedicado o lógicamente aislado para una organización y puede ejecutarse en la cuenta en la nube del proveedor, la cuenta en la nube del comprador o en una infraestructura alojada dedicada. La nube privada no se ubica automáticamente en las instalaciones de la empresa; es necesario definir el control, el aislamiento y la propiedad.
CPMS local
La plataforma se ejecuta en una infraestructura controlada por el cliente en su propio centro de datos, instalación o entorno de coubicación contratado. El cliente suele ser el principal responsable del hardware, los sistemas operativos, las bases de datos, la red, las copias de seguridad, la observabilidad y la recuperación.
Implementación híbrida
Los servicios o datos seleccionados permanecen en un entorno privado o local, mientras que otras funcionalidades se ejecutan en la nube. Un diseño híbrido permite mantener el control operativo o las integraciones sensibles en el entorno local, utilizando servicios en la nube para aplicaciones, análisis, actualizaciones o acceso global.
El Definición de computación en la nube según NIST La nube se describe como acceso bajo demanda a un conjunto compartido de recursos configurables que se pueden aprovisionar y liberar rápidamente. Esta elasticidad es valiosa, pero su contrato aún debe definir la tenencia, las regiones, las copias de seguridad, la disponibilidad y los derechos de salida.
Comparación entre sistemas de gestión de carga de vehículos eléctricos en la nube y en las instalaciones: una visión general
| Área de decisión | CPMS en la nube | Sistema de gestión de contraseñas (CPMS) local |
|---|---|---|
| Despliegue típico | Más rápido cuando se dispone de un entorno estándar, conectividad e integraciones. | El proceso es más largo cuando se requiere la adquisición de infraestructura, la aprobación de seguridad y la creación de un entorno adecuado. |
| Escalada | Por lo general, la capacidad se puede ampliar sin que el comprador tenga que instalar servidores físicos. | El comprador planifica, adquiere y opera la capacidad suficiente para el crecimiento y la demanda máxima. |
| Costo inicial | A menudo, los gastos de capital para infraestructura son menores; la configuración y la suscripción siguen siendo obligatorias. | A menudo, los costes iniciales de infraestructura, despliegue e ingeniería son más elevados. |
| Costo continuo | Suscripción, uso de la nube, soporte, integraciones, almacenamiento y transferencia de datos. | Ciclo de vida del hardware, instalaciones, licencias, personal de TI, monitorización, seguridad, copias de seguridad y soporte. |
| Control | El control depende del modelo de servicio, la configuración, el contrato y la titularidad de la cuenta. | Mayor control de la infraestructura, junto con una mayor responsabilidad operativa. |
| Ubicación de los datos | La región de nube y la arquitectura del proveedor seleccionadas deben cumplir con los requisitos de residencia. | El comprador selecciona la arquitectura de las instalaciones y del almacenamiento, teniendo en cuenta todos los servicios externos que se utilicen. |
| Actualizaciones | El proveedor puede coordinar las actualizaciones de la plataforma en todos los entornos gestionados. | El comprador y el vendedor deben planificar las actualizaciones, los parches, las dependencias y las ventanas de mantenimiento. |
| Resiliencia | La redundancia gestionada está disponible, pero debe diseñarse, contratarse y probarse. | El comprador financia y opera los sistemas de redundancia, respaldo, sitios secundarios y pruebas de recuperación. |
| Integraciones | Muy adecuado para API de internet y servicios externos distribuidos. | Útil para sistemas internos altamente controlados o rutas de red privadas. |
| Mejor ajuste | Empresas de compras por contrato (CPO), fabricantes de equipos originales (OEM), redes inmobiliarias, plataformas regionales y flotas distribuidas en constante crecimiento. | Organizaciones con necesidades específicas de aislamiento, soberanía, integración interna o control de infraestructura. |
Importante: La nube no implica automáticamente un bajo control, y la instalación local no implica automáticamente seguridad. La seguridad y la disponibilidad dependen de la arquitectura, la configuración, los controles de identidad, la disciplina operativa, la monitorización, la aplicación de parches, las copias de seguridad, las pruebas y la clara asignación de responsabilidades.
¿Cómo modifica el modelo de despliegue la arquitectura de CPMS?
La cadena funcional se mantiene prácticamente igual: los cargadores se comunican con el CPMS mediante OCPP; las interfaces de operador y conductor utilizan API; la plataforma gestiona usuarios, sesiones, tarifas y transacciones; y los servicios externos conectan pagos, roaming, mapas, sistemas energéticos, ERP o sistemas de gestión de flotas. El modelo de implementación varía según dónde se ejecutan estos componentes y quién los opera.
En una implementación en la nube, los cargadores generalmente se conectan a un punto final administrado a través de redes de área amplia seguras. En una implementación local, el punto final puede estar protegido por enrutamiento privado, VPN, firewalls o controles de red dedicados. Sin embargo, la plataforma aún puede necesitar conexiones de entrada y salida para proveedores de pago, aplicaciones móviles, SMS y correo electrónico, mapas, tiendas de aplicaciones, roaming, actualizaciones de software y soporte.
Esto significa que una plataforma de carga aislada (air-salied) tiene una arquitectura especial, no es un sinónimo común de instalación local. Puede limitar los servicios de control en tiempo real y las integraciones externas. Defina el modelo de conectividad exacto antes de asumir que el alojamiento local elimina la dependencia de internet.
10 factores a comparar antes de elegir un CPMS en la nube o local
1. Velocidad de despliegue y aprobación interna
La implementación en la nube puede reducir el trabajo de infraestructura necesario antes de que comiencen la configuración y las pruebas de los cargadores. Esto resulta útil para los operadores que necesitan lanzar un programa piloto, añadir un país o conectar nuevas ubicaciones rápidamente. Los proyectos locales suelen requerir dimensionamiento de servidores, adquisición, arquitectura de red, revisión de seguridad, estándares del sistema operativo, configuración de bases de datos, copias de seguridad y monitorización antes de que se pueda aceptar el CPMS.
Solicite cronogramas separados para la preparación del entorno, el despliegue de la aplicación, las integraciones, la incorporación de cargadores, las pruebas de seguridad, la aceptación del usuario y la puesta en producción. Una estimación breve de la instalación del software no es lo mismo que un plan de lanzamiento completo.
2. Escalabilidad y rendimiento
Las plataformas de carga procesan señales de actividad, cambios de estado, valores de medidores, comandos, sesiones, tarifas, transacciones, alertas e informes. El crecimiento no se mide únicamente por la cantidad de cargadores. Una red puede tener un volumen de hardware moderado, pero una alta frecuencia de telemetría, tráfico de API, sesiones concurrentes o carga de trabajo analítica.
Los entornos en la nube facilitan la expansión de la capacidad, pero el escalado no es automático a menos que la aplicación, la base de datos, las colas y las integraciones estén diseñadas para ello. Los sistemas locales también pueden escalar, pero el comprador debe planificar la capacidad, el plazo de adquisición, la redundancia y las pruebas de rendimiento.
Solicita información sobre los requisitos de cargadores, conectores, frecuencia de mensajes, sesiones concurrentes, usuarios activos, llamadas a la API, crecimiento del almacenamiento y ventanas de informes. Luego, define los criterios de aceptación de rendimiento en función de tu previsión, no del máximo genérico del proveedor.
3. Costo total de propiedad a cinco años
El software en la nube puede reducir la inversión en infraestructura, pero el precio de la suscripción es solo uno de los costos. Los precios de las soluciones locales pueden parecer atractivos si la licencia es perpetua, pero la mano de obra interna, la renovación del hardware, las licencias de bases de datos, las copias de seguridad, las herramientas de seguridad y la recuperación ante desastres pueden modificar sustancialmente el resultado.
Utilice esta estructura TCO: Implementación + licencias + infraestructura + consumo en la nube + integraciones + mano de obra operativa + monitoreo + seguridad y cumplimiento + copias de seguridad y recuperación ante desastres + actualizaciones + soporte + migración y salida.
Modela al menos tres escenarios de crecimiento. Incluye pagos, mensajería, mapas, roaming, transferencia de datos y almacenamiento cuando corresponda. Separa los cargos fijos, por cargador, por conector, por sesión, por usuario y basados en el consumo.
4. Responsabilidad en materia de seguridad
Los servicios en la nube siguen un modelo de responsabilidad compartida. Por ejemplo, AWS distingue entre la seguridad "de" la nube y la seguridad "en" la nube.El proveedor gestiona la infraestructura subyacente, mientras que los clientes conservan responsabilidades que varían según el servicio, incluyendo datos, identidades, aplicaciones y configuración.
Con la implementación local, generalmente se transfieren más capas al cliente: acceso físico, hipervisores, sistemas operativos, bases de datos, reglas de firewall, certificados, parches, protección de endpoints, registros, copias de seguridad y recuperación. Esto solo puede mejorar el control directo si la organización cuenta con el personal, las herramientas y la disciplina de gestión de cambios necesarios para operar esos controles de manera consistente.
| capa de seguridad | Ejemplo de nube gestionada | Ejemplo de instalación local |
|---|---|---|
| Instalaciones y hardware físico | Responsabilidad principalmente del proveedor de infraestructura en la nube. | Responsabilidad del cliente o del proveedor de servicios de colocación. |
| Sistema operativo, base de datos y middleware | Depende del tipo de entrega (SaaS, PaaS o IaaS) y del contrato. | Normalmente, la coordinación entre el cliente y el proveedor del sistema de gestión de la privacidad (CPMS). |
| Seguridad de la aplicación CPMS | Responsabilidad del proveedor en las tareas de configuración del cliente. | Código del proveedor, además del entorno y los controles operados por el cliente. |
| Usuarios, roles, MFA y SSO | Compartido: capacidad del proveedor, gobernanza de la identidad del cliente. | Compartido: capacidad de la aplicación e infraestructura de identidad del cliente. |
| Certificados y credenciales del cargador | Debe asignarse explícitamente entre el proveedor, el comprador y el fabricante del cargador. | El mismo requisito; el alojamiento local no determina la propiedad. |
| Respuesta ante incidentes | Proceso conjunto entre el proveedor, el proveedor del sistema de gestión de la concentración (CPMS) y el operador. | Proceso conjunto que involucre a los departamentos de TI/OT del cliente, al proveedor y a los terceros afectados. |
5. Soberanía, privacidad y propiedad de los datos
La soberanía de los datos no se resuelve preguntando dónde está el servidor. Se deben gestionar la telemetría de los cargadores, los datos de las cuentas, los tokens de pago, las facturas, los tickets de soporte, las copias de seguridad, los registros, los análisis, las notificaciones push móviles y los subprocesadores. Una plataforma en la nube suele utilizar una región específica, mientras que una plataforma local puede enviar datos a servicios externos de pago, notificación o mapas.
Defina las funciones del controlador y del procesador, las categorías de datos, la residencia, la retención, la eliminación, las ubicaciones de copia de seguridad, las transferencias transfronterizas y el soporte al interesado. Confirme contractualmente quién es el propietario de los datos del cargador, la sesión, el cliente, los precios, las transacciones, los fallos, el mantenimiento y los datos analíticos derivados. Sistema de gestión de puntos de recarga para vehículos eléctricos Esta página describe las cuestiones relativas al despliegue y a los datos operativos que los compradores deberían plantear durante la fase de definición del alcance.
6. Disponibilidad, copias de seguridad y recuperación ante desastres
La infraestructura en la nube proporciona los elementos básicos para la redundancia, pero la arquitectura y el nivel de servicio determinan el resultado final. La infraestructura local también puede ser muy resiliente, pero es necesario financiar y gestionar un segundo sitio, bases de datos replicadas, conectividad redundante, capacidad de reserva y pruebas de recuperación.
Solicite un diagrama de servicio y confirme:
- la definición del tiempo de actividad y el punto de medición;
- diseño de zona única, multizona o multirregión;
- Pruebas de frecuencia, retención, inmutabilidad y restauración de copias de seguridad;
- objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO);
- Comportamiento del cargador cuando el sistema o la red no están disponibles;
- Pago, autorización y conciliación de transacciones después de la reconexión.
7. Actualizaciones, evolución de OCPP y ciclo de vida del software
Las plataformas gestionadas en la nube pueden coordinar las actualizaciones de las aplicaciones de forma centralizada, lo que permite a los operadores recibir correcciones y mejoras de productos sin tener que reconstruir su propia infraestructura. Esta ventaja requiere una gobernanza de versiones: notificaciones, ventanas de mantenimiento, compatibilidad con versiones anteriores, pruebas de regresión y reversión.
Los clientes que utilizan sistemas locales suelen exigir un control de cambios más estricto, pero las actualizaciones tardías pueden generar fragmentación de versiones y aumentar la exposición a vulnerabilidades conocidas. Es necesario acordar qué versiones son obligatorias, cuánto tiempo se les da soporte, quién prueba las dependencias de la base de datos y del sistema operativo, y cómo se aprueban los parches de emergencia.
El Open Charge Alliance actualmente incluye OCPP 1.6, 2.0.1 y 2.1.Su modelo de implementación debe admitir un protocolo realista y una hoja de ruta para el firmware del cargador, en lugar de congelar la red en su configuración inicial.
8. Integraciones y conectividad de red
Los sistemas CPMS en la nube suelen integrarse eficazmente con pasarelas de pago, aplicaciones, redes de roaming y API empresariales basadas en internet. La implementación local simplifica el acceso controlado a sistemas internos de ERP, identidad, flota, servicios públicos o tecnología operativa, pero puede requerir pasarelas API, proxies inversos, VPN, listas de permitidos y revisión de seguridad para cada conexión externa.
Documente la dirección de los datos, la autenticación, los certificados, los rangos de IP, los puertos, la latencia, los límites de velocidad, los reintentos y el comportamiento ante fallos. Decida quién supervisa cada conexión y quién se responsabiliza de los incidentes en la interfaz entre sistemas.
9. Operaciones, monitoreo y soporte
La decisión sobre el alojamiento modifica el funcionamiento del soporte. En la nube gestionada, el proveedor de CPMS suele tener mayor control sobre la aplicación y la plataforma. En la infraestructura controlada por el cliente, el soporte puede depender de la autorización de acceso remoto, los registros proporcionados por el cliente, el estado del entorno, las sesiones programadas y la coordinación entre varios equipos.
Defina la responsabilidad de la monitorización para la infraestructura, los servicios de aplicaciones, la base de datos, las integraciones, la caducidad de certificados, las conexiones OCPP y los flujos de trabajo empresariales. gestión inteligente de operaciones Las funcionalidades demuestran cómo la monitorización del cargador, el diagnóstico, la reparación remota y las órdenes de trabajo pueden conformar un único proceso de operación y mantenimiento.
10. Portabilidad, dependencia y planificación de salida
Todos los modelos pueden generar dependencia. La dependencia en la nube puede deberse a servicios gestionados, API propietarias, condiciones comerciales o datos operativos inaccesibles. La dependencia en entornos locales puede deberse a infraestructura personalizada, dependencias especializadas, versiones sin soporte o código fuente que el comprador no puede mantener.
Se requieren exportaciones de datos completas, esquemas documentados, acceso a la API, titularidad de las credenciales del cargador, copias de seguridad de la configuración, titularidad de la tienda de aplicaciones y del dominio, términos del código fuente cuando corresponda y un período de transición definido. El plan de salida debe incluir la migración del punto final del cargador, los cambios de certificado, los registros históricos, la conciliación de pagos y la evidencia de eliminación.
¿Quién debería elegir un sistema de gestión de carga de vehículos eléctricos en la nube?
La implementación en la nube suele ser una opción muy adecuada cuando la mayoría de estas afirmaciones son ciertas:
Entre los candidatos típicos se incluyen operadores regionales de carga de vehículos eléctricos, fabricantes de cargadores para vehículos eléctricos que lanzan un servicio de marca, redes de propiedades, empresas de carga en destino, redes de carga públicas y flotas comerciales distribuidas. Para interfaces de clientes y operadores de marca, consulte TrendPower. software de carga de vehículos eléctricos de marca blanca.
¿Quién debería elegir un sistema CPMS local?
La implementación local merece una evaluación seria cuando se cumplen varias de estas condiciones:
Entre los candidatos típicos se incluyen empresas de servicios públicos, entornos del sector público, grandes flotas de depósitos, operadores de transporte, proyectos de infraestructura crítica o empresas con estándares de nube privada establecidos. La implementación local debe ser una opción arquitectónica sólida, respaldada por la capacidad operativa, y no una respuesta automática a preocupaciones generales de seguridad.
¿Cuándo es mejor una arquitectura de carga para vehículos eléctricos híbridos?
El enfoque híbrido puede ser útil cuando los requisitos difieren realmente según la carga de trabajo. Algunos ejemplos son:
- mantener un controlador de energía a nivel de depósito y una lógica de carga local en las instalaciones, al tiempo que se centralizan los análisis de la flota en la nube;
- conservar determinados datos regulados en un entorno privado al utilizar aplicaciones en la nube y servicios de carga públicos;
- Proporcionar continuidad local para el control del cargador al tiempo que sincroniza las sesiones y los informes con un CPMS central;
- conectar un sistema empresarial local a través de una capa de integración controlada en lugar de trasladar todo el sistema CPMS a nivel local.
La arquitectura híbrida también introduce más interfaces, estados de sincronización y límites de soporte. Permite definir la fuente de información fidedigna, la duración sin conexión, la resolución de conflictos, las transacciones diferidas, la sincronización horaria, la gestión de certificados y la responsabilidad en caso de discrepancia entre las capas local y en la nube.
Marco práctico para la toma de decisiones sobre el despliegue
Utilice estas preguntas antes de solicitar la arquitectura y el presupuesto definitivos:
- ¿Cuál de estos requisitos no es negociable? Identificar restricciones vinculantes de residencia, aislamiento, latencia, integración o propiedad, en lugar de preferencias.
- ¿Qué debe seguir funcionando sin conexión a internet? Separar el comportamiento del cargador local del de las aplicaciones, los pagos, la itinerancia, los informes y las operaciones remotas.
- ¿Quién puede operar la pila? Nombre el equipo responsable de la infraestructura, el sistema operativo, la base de datos, las redes, la seguridad, la observabilidad y la recuperación.
- ¿Con qué rapidez crecerá la red? Modelo de cargador, conector, usuario, sesión, telemetría, API y volúmenes de almacenamiento.
- ¿Dónde debe residir cada tipo de dato? Incluya registros, copias de seguridad, análisis, notificaciones y subprocesadores, no solo la base de datos de producción.
- ¿Qué sistemas deben integrarse? Plataformas de pago, ERP, CRM, SSO, flota, energía, roaming, mapas, soporte y datos.
- ¿Qué disponibilidad se requiere realmente? Defina el tiempo de actividad, el RTO, el RPO, las ventanas de mantenimiento y el funcionamiento en modo degradado.
- ¿Cómo evolucionará el sistema? Planificar las actualizaciones de OCPP, firmware del cargador, pago, API, seguridad y aplicaciones.
- ¿Cuál es el costo total de propiedad a cinco años? Incluya la mano de obra y los riesgos internos, no solo las facturas de los proveedores.
- ¿Cómo te irás? Pruebe la exportación, las credenciales, la configuración, la migración del cargador y la asistencia para la transición antes de firmar.
Convierta las respuestas en un documento de adquisición estructurado utilizando el Lista de verificación de la solicitud de propuestas (RFP) para sistemas de gestión de carga de vehículos eléctricosSolicitar respuestas separadas sobre arquitectura, responsabilidad, implementación y costos para cada modelo de despliegue propuesto.
Cómo TrendPower aborda la implementación flexible de CPMS
TrendPower diseña el software de carga de vehículos eléctricos en función del hardware del operador, los mercados objetivo, el flujo de trabajo comercial, las integraciones y los requisitos de control. La plataforma, más amplia, admite opciones de implementación en la nube pública, la nube privada y proyectos específicos, y se evalúan los servicios locales cuando los requisitos de datos, seguridad e integración del cliente así lo exigen.
La decisión de implementación no reemplaza la validación funcional. Los compradores aún deben confirmar la compatibilidad del modelo de cargador y firmware, las funciones OCPP, los proveedores de pago, los roles de usuario, las tarifas, los informes, las API, la monitorización, el alcance del soporte y las responsabilidades de migración. 15 capacidades esenciales de CPMS Esta guía proporciona un marco de evaluación a nivel de funcionalidades.
Los proyectos que requieren un flujo de trabajo más profundo o una integración empresarial también pueden definirse a través de un Solución de software personalizada para la carga de vehículos eléctricosPara ver un ejemplo de una plataforma de marca que conecta cargadores, control remoto, programación, permisos, pagos y liquidación del propietario, consulte la Estudio de caso de una plataforma de carga de vehículos eléctricos domésticos en EE. UU..
Compare las opciones en la nube, privadas, híbridas y locales.
Comparta sus modelos de cargadores, pronóstico de red, países objetivo, requisitos de datos, integraciones, objetivos de disponibilidad y capacidades de TI internas. TrendPower puede ayudarle a definir el alcance y la demostración de una implementación práctica de CPMS con estos datos.
Preguntas frecuentes sobre software de carga de vehículos eléctricos en la nube frente a software local
¿Es mejor un sistema CPMS en la nube o uno local para la carga de vehículos eléctricos?
Ninguna opción es universalmente mejor. La nube suele ser más práctica para redes distribuidas que requieren un despliegue más rápido, una escalabilidad más sencilla y operaciones de plataforma gestionadas. Las soluciones locales pueden ser apropiadas cuando los requisitos verificados de datos, red, integración o control de infraestructura justifican la responsabilidad operativa adicional.
¿Es más seguro el software de carga de vehículos eléctricos instalado localmente que el software en la nube?
No automáticamente. La infraestructura local ofrece un control más directo, pero el cliente debe proteger y mantener capas adicionales. La nube permite heredar sólidos controles físicos y de infraestructura, dejando las responsabilidades de las aplicaciones, la identidad, los datos y la configuración en manos del proveedor y el cliente. Compare los controles, las evidencias y las responsabilidades, en lugar de basarse únicamente en la ubicación.
¿Puede el software de carga de vehículos eléctricos en la nube cumplir con los requisitos de residencia de datos?
A menudo, pero depende de las regiones disponibles, la arquitectura, las copias de seguridad, los registros, los subprocesadores, el acceso al soporte y los términos del contrato. Mapee cada flujo de datos relevante y valídelo con respecto a la jurisdicción, la política y los requisitos legales del comprador.
¿Cuál es la diferencia entre la nube privada y un sistema CPMS local?
La nube privada describe un entorno aislado para una organización, que puede ejecutarse en un proveedor de nube, una instalación gestionada por el proveedor o una cuenta de cliente. El término "en las instalaciones" generalmente significa que la plataforma se ejecuta en una infraestructura controlada en las propias instalaciones o centro de datos del cliente. La propiedad y la responsabilidad operativa deben estar definidas en la arquitectura.
¿Pueden seguir funcionando los cargadores de vehículos eléctricos si se pierde la conexión con la nube?
Algunas configuraciones de cargadores y sistemas CPMS admiten autorización sin conexión definida, comportamiento local o transacciones en cola, pero la funcionalidad varía según el cargador, el firmware, la implementación de OCPP y las reglas de negocio. Pruebe la autorización, la facturación, la medición, el cierre de transacciones, el pago y la conciliación durante un programa piloto.
¿Es más caro el despliegue híbrido?
Esto puede deberse a que la organización opera e integra capas tanto locales como en la nube. La arquitectura híbrida resulta ventajosa cuando resuelve un requisito específico, como la continuidad local, la integración privada o el control selectivo de datos. Evite la complejidad de la arquitectura híbrida si un entorno único bien diseñado satisface el requisito.
¿Qué debe incluirse en una propuesta de implementación de CPMS?
Incluya la arquitectura, la propiedad del entorno, las ubicaciones de los datos, las responsabilidades de seguridad, el diseño de disponibilidad, la copia de seguridad y la recuperación, la conectividad, las integraciones, la monitorización, el acceso al soporte, el proceso de lanzamiento, el plan de implementación, las pruebas de aceptación, la fijación de precios completa, la migración y la asistencia para la salida.
Fuentes autorizadas y lecturas adicionales
- NIST SP 800-145 — Definición de computación en la nube según el NIST
- Amazon Web Services: Modelo de Responsabilidad Compartida
- Alianza de Carga Abierta — Protocolos OCPP
- Marco de ciberseguridad del NIST
Revisado para determinar su relevancia técnica y de adquisición: 20 de septiembre de 2026. Los requisitos de alojamiento, privacidad, seguridad y normativas varían según la jurisdicción y el proyecto. Valide la arquitectura final con sus equipos técnicos, legales y de cumplimiento.
ES 
EN 
ZH 
AR 
DE 
KO 
JA 
IT 
FR 
VI 
MS 
ID 
FR_CA 
NL 
SV 
EN_GB 
TH 