RS485 frente a CAN para BMS de baterías industriales: cómo los OEM eligen la interfaz de comunicación adecuada

Elegir entre RS485 y CAN para un BMS de batería industrial no es simplemente una cuestión de comparar la velocidad de comunicación.

La elección correcta depende de la arquitectura del equipo OEM, la tasa de actualización requerida, la topología de la red, la compatibilidad del controlador, la estrategia de manejo de fallas, los recursos de software y el flujo de trabajo de diagnóstico.

Más importante aún, un conector RS485 o CAN no garantiza la compatibilidad. Dos dispositivos pueden usar la misma interfaz física pero aun así no logran comunicarse porque su velocidad en baudios, formato de mensaje, direccionamiento, escala, sincronización o protocolo de aplicación son diferentes.

Por lo tanto, para los ingenieros OEM, la verdadera pregunta no es sólo “¿RS485 vs CAN?” Es:

¿Qué arquitectura de comunicación puede intercambiar de forma fiable los datos y comandos necesarios de la batería durante la vida útil del equipo?

La respuesta corta: ¿Cuándo debería elegir RS485 o CAN?

RS485 suele ser adecuado cuando el sistema utiliza un dispositivo maestro definido, sondeo relativamente predecible, velocidades de actualización moderadas y una red simple punto a punto o multipunto.

CAN suele ser adecuado cuando varios controladores necesitan comunicación basada en eventos, priorización de mensajes, control distribuido, informes rápidos de fallas o integración con una red de máquinas basada en CAN existente.

Factor de selección	RS485	PODER
Modelo de comunicación típico	Maestro-esclavo o cliente-servidor	Comunicación multinodo basada en mensajes
Intercambio de datos común	Encuesta y respuesta	Mensajes de difusión y basados ​​en eventos
Acceso a la red	Controlado por el protocolo maestro o de aplicación.	Arbitraje de mensajes basado en la prioridad del identificador
Esfuerzo de integración	A menudo es más sencillo para el seguimiento básico	A menudo se adapta mejor a sistemas distribuidos en tiempo real.
Protocolo de capa superior	Modbus RTU o protocolo propietario	CANopen, J1939 o protocolo propietario
Uso típico	Monitorización, configuración y control de supervisión	Maquinaria móvil, robots, AGV y controladores distribuidos
Riesgo principal	Mismo hardware RS485 pero protocolo serial diferente	Mismo hardware CAN pero definiciones de mensajes incompatibles

Esta comparación es sólo un punto de partida. La decisión final debe basarse en los requisitos de comunicación completos del equipo.

RS485 y CAN no son el mismo tipo de especificación

Una de las razones por las que las discusiones entre RS485 y CAN se vuelven confusas es que los dos términos no describen exactamente la misma parte de un sistema de comunicación.

RS485 define principalmente una interfaz eléctrica para comunicación serie equilibrada. Describe cómo se transmiten las señales eléctricas entre los conductores y los receptores, pero no define qué significan los datos.

Instrumentos de Texas Guía de diseño RS-485 describe RS485 como un estándar exclusivamente eléctrico ampliamente utilizado en aplicaciones industriales.

Por lo tanto, una implementación completa del BMS de batería RS485 también requiere un protocolo de aplicación, como por ejemplo:

• Modbus RTU.

• Un protocolo de registro específico del fabricante.

• Un formato propietario de comando y respuesta.

• Otro protocolo serial documentado.

CAN incluye una capa de enlace de datos, así como opciones definidas de capa física. El controlador CAN maneja funciones como la transmisión de tramas, el arbitraje, la detección y el reconocimiento de errores. Sin embargo, CAN todavía no define automáticamente el significado de los datos de la batería.

Un BMS de batería de bus CAN puede utilizar:

• CANabierto.

• SAE J1939.

• Protocolo propietario de un fabricante de vehículos o equipos.

• Mapa de mensajes propietario de un proveedor de baterías.

El Descripción general de CAN en automatización Explica que las capas inferiores de CAN están estandarizadas mediante la serie ISO 11898. Todavía se necesitan protocolos de capa superior para definir cómo los dispositivos intercambian datos de aplicaciones.

Por lo tanto:

RS485 o CAN define cómo pueden viajar los datos. El protocolo de comunicación BMS define qué significan los datos y cómo debe responder el equipo.

¿Qué información debe intercambiarse la batería BMS?

Antes de seleccionar una interfaz, defina la información que el controlador OEM realmente necesita.

Los datos BMS comunes pueden incluir:

• Voltaje del paquete.

• Corriente de carga y descarga.

• Estado de carga.

• Estado de salud, cuando sea compatible.

• Tensión de celda mínima y máxima.

• Datos de temperatura de batería y celda.

• Permiso de carga y descarga.

• Límites de corriente o potencia recomendados.

• Estado de alarma y protección.

• Estado del contactor o relé.

• Estado de conexión del cargador.

• Versión de firmware y hardware.

• Historial de fallas o información de diagnóstico.

• Energía restante o estimación de tiempo de ejecución.

Algunos sistemas también requieren comandos del controlador host, como por ejemplo:

• Solicitud de despertar o dormir.

• Control de contactores.

• Restablecimiento de fallas.

• Selección del modo de funcionamiento.

• Activar o desactivar la carga.

• Solicitud de límite actual.

• Comandos de servicio o calibración.

No asuma que todos los BMS admiten todas estas funciones. Cada señal requerida debe clasificarse como obligatoria, opcional o sólo de diagnóstico.

Cómo funciona la comunicación BMS de batería RS485

RS485 comúnmente usa un par diferencial para transmitir datos en serie. Dependiendo del diseño, puede utilizar una configuración semidúplex de dos cables o full-duplex de cuatro cables.

En muchas aplicaciones de baterías, un controlador host, una pantalla, una puerta de enlace o un cargador actúan como maestro. Envía una solicitud a una dirección de batería definida y la batería devuelve los datos solicitados.

Una secuencia típica puede ser:

1. El host solicita voltaje del paquete.

2. El BMS valida la dirección y el comando.

3. El BMS devuelve el valor y los datos de verificación de errores.

4. El host solicita el estado actual, de temperatura o de alarma.

5. El ciclo electoral se repite.

Ventajas de RS485 para la integración de batería BMS

RS485 puede ser una opción práctica cuando:

• El controlador OEM ya incluye un puerto RS485.

• El sistema tiene un maestro claro.

• La información de la batería se puede recopilar mediante sondeos periódicos.

• La tasa de actualización requerida es moderada.

• Una red multipunto simple es suficiente.

• Ya se utiliza Modbus RTU u otro protocolo documentado.

• El equipo de ingeniería tiene experiencia en comunicaciones en serie.

El funcionario Página de especificaciones de Modbus proporciona el protocolo de aplicación Modbus actual y una guía de implementación de línea serie. La Organización Modbus recomienda su Guía de implementación y protocolo de línea serie V1.02 para nuevas implementaciones en serie.

Limitaciones y riesgos de RS485

RS485 no define:

• Direcciones de dispositivos.

• Registrar ubicaciones.

• Escalado de datos.

• Orden de bytes.

• Significados de los comandos.

• Intervalos de sondeo.

• Comportamiento de tiempo de espera.

• Recuperación de fallos.

• Seguridad o autenticación.

Estos elementos pertenecen al protocolo de solicitud.

El sondeo también puede crear latencia. Si un controlador sondea varias baterías y muchos registros secuencialmente, es posible que el mensaje de falla más importante deba esperar hasta la siguiente solicitud programada.

Ese retraso puede ser aceptable para un sistema de monitoreo pero inadecuado para un circuito de control rápido. El requisito debe cuantificarse en lugar de asumirse.

Cómo funciona la comunicación BMS de la batería del bus CAN

CAN utiliza identificadores de mensajes en lugar de un modelo simple de dirección de destino. Los dispositivos monitorean el bus compartido y procesan los mensajes relevantes para ellos.

Cuando más de un nodo intenta transmitir, el arbitraje CAN permite que el mensaje de mayor prioridad continúe sin corromper la trama ganadora. Esto hace que CAN sea adecuado para sistemas donde varios controladores deben compartir datos urgentes.

El controlador CAN también proporciona detección y señalización de errores a nivel de cuadro integradas. Estas características mejoran la solidez de la comunicación, pero no reemplazan la necesidad de un diseño correcto del sistema, cableado y manejo de fallas a nivel de aplicación.

Ventajas de CAN para la integración de batería BMS

CAN puede ser una buena opción cuando:

• La máquina ya dispone de una red CAN.

• Varios controladores necesitan información de la batería.

• Las fallas deben informarse sin esperar un ciclo de sondeo.

• Mensajes diferentes necesitan prioridades diferentes.

• El sistema utiliza control distribuido en tiempo real.

• El OEM ya admite CANopen, J1939 o un protocolo propietario definido.

• Los analizadores de bus, los archivos DBC o las herramientas de diagnóstico CAN forman parte del proceso de desarrollo.

CAN in Automation enumera enfoques estandarizados de capa superior que incluyen Perfiles basados ​​en CANopen y J1939 . La selección del hardware CAN por sí sola no determina cuál de estos protocolos se está utilizando.

Limitaciones y riesgos de CAN

Un puerto CAN no garantiza la compatibilidad con otro dispositivo CAN.

El OEM aún necesita confirmar:

• CAN clásico, CAN FD u otra variante.

• Tasa de bits nominal.

• Formato del identificador.

• Identificadores estándar o extendidos.

• Identificadores de mensajes.

• Longitud de los datos.

• Orden de bytes.

• Escalado y compensación.

• Periodo de transmisión.

• Condiciones desencadenadas por eventos.

• Límites de tiempo de espera.

• Comportamiento de inicio del nodo.

• Recuperación de fallos.

• Protocolo de capa superior requerido.

Una batería que utiliza mensajes CAN propietarios no se comunicará automáticamente con un controlador diseñado para CANopen o J1939.

Arquitectura RS485 frente a CAN

Figura 1. RS485 comúnmente usa comunicación controlada de solicitud-respuesta, mientras que CAN admite transmisión de mensajes distribuidos y arbitraje basado en identificadores. Aún debe definirse el protocolo de aplicación exacto para ambos.

RS485 vs CAN: Comparación detallada de OEM

Topología de red

RS485 suele utilizar una disposición troncal o en cadena con ramas cortas de dispositivos. CAN también utiliza una topología de bus lineal con terminación en ambos extremos.

No se debe asumir que el cableado en estrella es seguro para ninguna de las interfaces. Las ramas largas y el tendido incontrolado de cables pueden crear reflejos y problemas de integridad de la señal.

La topología permitida depende de:

• Longitud del cable.

• Velocidad de bits o baudios.

• Longitud del trozo.

• Características del transceptor.

• Terminación.

• Impedancia del cable.

• Entorno electromagnético.

Momento de la comunicación

La sincronización RS485 suele estar controlada por el programa de sondeo del maestro. Los ingenieros pueden estimar la antigüedad de los datos en el peor de los casos calculando:

• Número de dispositivos.

• Número de solicitudes por dispositivo.

• Longitud del marco.

• Velocidad en baudios.

• Retraso en la respuesta.

• Vuelva a intentar contar.

• Periodo de tiempo de espera.

CAN comúnmente utiliza transmisión periódica o activada por eventos. En cambio, los ingenieros deben evaluar:

• Utilización del autobús.

• Prioridad del mensaje.

• Intervalo de transmisión.

• En el peor de los casos, retraso en el arbitraje.

• Comportamiento del marco de error.

• Monitoreo de tiempo de espera.

Ninguna arquitectura es automáticamente más rápida en todos los sistemas reales. Un protocolo RS485 bien diseñado puede superar a una red CAN sobrecargada, mientras que un sistema CAN con la prioridad adecuada puede informar fallas críticas más rápido que un ciclo de sondeo largo.

Manejo de fallas

Para RS485, la aplicación normalmente necesita detectar respuestas faltantes, sumas de verificación no válidas, direcciones duplicadas y tiempos de espera de comunicación.

Para CAN, el controlador proporciona mecanismos de error a nivel de trama, pero la aplicación aún debe decidir qué hacer cuando:

• Un mensaje requerido deja de llegar.

• Se reinicia un nodo.

• Los datos se vuelven obsoletos.

• El bus entra en estado de error.

• Una batería informa una alarma de protección.

• Dos dispositivos utilizan identificadores contradictorios.

La salud de las comunicaciones debe convertirse en una respuesta segura de los equipos.

Diagnóstico

Los diagnósticos RS485 pueden utilizar:

• Software de terminal serie.

• Analizadores de protocolos.

• Herramientas de lectura de registros.

• Osciloscopios.

• Adaptadores USB a RS485.

• Contadores y registros de comunicaciones.

Los diagnósticos CAN pueden utilizar:

• Analizadores de bus CAN.

• Archivos DBC o EDS.

• Herramientas de diagnóstico CANopen o J1939.

• Osciloscopios.

• Análisis de carga de autobuses.

• Contadores de errores y registros de mensajes.

El equipo de servicio debe recibir herramientas y documentación que coincidan con el protocolo seleccionado.

Los documentos de compatibilidad más importantes

Antes de aprobar una batería RS485 o CAN, solicite un paquete de comunicación que contenga los siguientes elementos.

1. Definición de interfaz

• RS485, CAN clásico o CAN FD.

• Configuración half-duplex o full-duplex, cuando corresponda.

• Interfaz aislada o no aislada.

• Fabricante del conector y número de pieza.

• Asignación de pines.

• Requisitos de cables y blindajes.

• Requisitos del terreno de referencia.

2. Configuración de red

• Velocidad en baudios o velocidad de bits CAN.

• Dirección del dispositivo o nodo.

• Formato del identificador.

• Requisitos de terminación.

• Requisitos de polarización para RS485.

• Recuento máximo de nodos.

• Longitud de cable y topología recomendadas.

• Procedimiento de puesta en marcha y descubrimiento.

3. Diccionario de mensajes

Para cada mensaje o registro documentar:

• Nombre.

• Identificador o dirección de registro.

• Tipo de datos.

• Orden de bytes.

• Escalada.

• Compensar.

• Unidad.

• Rango válido.

• Intervalo de actualización.

• Permisos de lectura o escritura.

• Comportamiento cuando el valor no está disponible.

4. Mapeo de alarmas y protecciones

Defina cómo informa el BMS:

• Sobretensión.

• Subtensión.

• Sobrecorriente.

• Cortocircuito.

• Temperatura alta o baja.

• Fallo de comunicación.

• Fallo del contactor.

• Fallo del sensor.

• Desequilibrio celular, cuando sea compatible.

• Restricciones de carga y descarga.

5. Reglas de tiempo de espera y recuperación

Especificar:

• Cuando los datos se vuelven obsoletos.

• ¿Cuántos reintentos se permiten?

• Qué debe hacer el anfitrión después del tiempo de espera.

• Cómo se despierta el BMS del sueño.

• ¿Qué sucede después del ciclo de energía?

• Si las fallas se solucionan automáticamente o requieren un comando.

• Cómo las versiones de firmware afectan la compatibilidad.

Opciones de comunicación pública de Dailymag Energy

La información pública del producto de Dailymag Energy muestra que los requisitos de comunicación varían según la configuración de la batería.

El publicado Página de batería de 25,2 V 10,2 Ah enumera la comunicación RS485.

El publicado Página de batería de 51,2 V 108 Ah enumera comunicación RS485 y CAN.

Estos listados confirman que las opciones de comunicación física aparecen en las configuraciones publicadas. No confirman que un Modbus, CANopen, J1939 o un protocolo propietario en particular funcionen con el controlador de un cliente.

Se debe confirmar la compatibilidad del protocolo, la documentación de los mensajes, la definición del conector y el comportamiento del software para el proyecto específico.

Los compradores pueden revisar el más amplio Gama de productos Dailymag Energía , pero la interfaz final debería congelarse sólo después de una revisión técnica.

Ocho preguntas que determinan la interfaz correcta

1. ¿Qué interfaz admite el controlador existente?

El uso de una interfaz de controlador existente puede reducir los cambios de hardware y software. Sin embargo, aún es necesario confirmar la compatibilidad del protocolo.

2. ¿La batería se une a una red existente?

Si la máquina ya utiliza CANopen, J1939 o una red CAN patentada, puede ser lógico agregar otro dispositivo CAN. Si la batería se conecta sólo a una pantalla o puerta de enlace, RS485 puede ser suficiente.

3. ¿Con qué rapidez deben llegar los datos críticos?

Defina los requisitos de temporización reales para límites de corriente, alarmas de temperatura, estado de carga bajo y eventos de protección.

El “tiempo real” no es un requisito mensurable. Especifique un retraso máximo aceptable.

4. ¿Cuántos dispositivos compartirán el bus?

Considere baterías, cargadores, pantallas, inversores, controladores, puertas de enlace y herramientas de servicio. La red debe revisarse como un sistema completo.

5. ¿Quién controla la comunicación?

Un sistema de supervisión simple puede funcionar bien con un sondeo RS485 controlado por maestro. Una máquina distribuida puede beneficiarse de la comunicación basada en eventos de CAN.

6. ¿Qué herramientas de diagnóstico utiliza ya el equipo?

Es posible que los equipos de desarrollo y servicio ya tengan herramientas Modbus, analizadores CAN, flujos de trabajo DBC o bibliotecas de controladores. La reutilización de herramientas probadas puede reducir el riesgo de integración.

7. ¿Cómo se gestionarán las versiones futuras?

Agregar nuevos campos de datos no debería dañar el equipo existente. Defina registros reservados, control de versiones de mensajes, reglas de compatibilidad e identificación de firmware.

8. ¿Qué sucede cuando falla la comunicación?

El equipo necesita una respuesta segura cuando faltan datos de la batería, están retrasados, son inverosímiles o inconsistentes.

No espere hasta las pruebas de campo para definir este comportamiento.

Un proceso de validación de comunicación BMS de seis etapas

Una integración confiable debe pasar por etapas de ingeniería controladas.

Etapa 1: definir los datos y comandos necesarios

Identificar cada señal que necesita el equipo. Clasifica cada uno como obligatorio, opcional o diagnóstico.

Etapa 2: Confirmar la interfaz física

Verifique los transceptores, las clavijas de los conectores, el aislamiento, la tierra de referencia, el blindaje, las terminaciones y los requisitos de los cables.

Etapa 3: construir la red

Cree la topología deseada con la longitud real del cable, el número de dispositivos, la terminación y la disposición de las ramas.

Etapa 4: Mapear el protocolo

Implemente identificadores, registros, escalado, orden de bytes, temporización de mensajes, comandos, alarmas y reglas de tiempo de espera.

Etapa 5: Prueba de banco de condiciones normales y de falla

Prueba:

• Arranque normal.

• Batería en suspensión y activación.

• Reinicio del controlador.

• Mensajes faltantes.

• Marcos corruptos o no válidos.

• Dirección o identificador incorrecto.

• Cable desconectado.

• Bus en cortocircuito o circuito abierto.

• Reintentos repetidos.

• Alto tráfico de autobuses.

• Eventos de protección BMS.

Etapa 6: Validar la máquina completa

Pruebe la batería, el controlador, el cargador y el equipo juntos bajo carga, temperatura y condiciones electromagnéticas representativas.

Figura 2. La validación de la comunicación debe avanzar desde los requisitos y el cableado hasta el mapeo de protocolos, el diagnóstico de banco y las pruebas de la máquina completa.

Fallos comunes de comunicación BMS

Conector correcto, distribución de pines incorrecta

Dos productos pueden usar la misma carcasa de conector pero asignar pines de alimentación, tierra y comunicación de manera diferente. Una coincidencia visual no es evidencia de compatibilidad.

Interfaz correcta, protocolo incorrecto

Un BMS RS485 que utilice comandos propietarios no funcionará automáticamente con un controlador Modbus. Un CAN BMS que utilice marcos propietarios no funcionará automáticamente con equipos CANopen o J1939.

Terminación faltante o incorrecta

Una terminación inadecuada puede provocar reflejos, errores de comunicación o fallos intermitentes. Verifique la terminación a nivel de red en lugar de agregar resistencias a cada dispositivo.

Escalado de datos incorrecto

Un valor bruto de 512 puede significar 51,2 V, 5,12 V o algo más dependiendo de la escala. Se deben documentar las unidades, los valores con signo, el orden de los bytes y las compensaciones.

No coincide el tiempo de espera

El host puede marcar los datos como no válidos antes del siguiente mensaje programado del BMS. Alternativamente, el host puede continuar usando datos obsoletos durante demasiado tiempo.

Conflicto de vigilia y sueño

El BMS puede entrar en modo de bajo consumo mientras el controlador espera una comunicación continua. Se deben acordar las fuentes y el momento de la estela.

Puesta a tierra y ruido electromagnético

Una conexión a tierra, blindaje o aislamiento de referencia inadecuados pueden crear errores incluso cuando la comunicación en el banco parece estable. Pruebe con la máquina real, el cargador, el motor y el enrutamiento de cables.

La seguridad debe definirse encima de la interfaz

No asuma que RS485 o CAN proporciona automáticamente autenticación, cifrado o control de acceso.

CAN in Automation señala que los protocolos de enlace de datos CAN estandarizados no proporcionan medidas de seguridad inherentes. Del mismo modo, una implementación básica de Modbus en serie no debe tratarse como un canal de comunicación seguro simplemente porque utiliza RS485.

Si el acceso no autorizado o la manipulación de mensajes son parte del modelo de amenaza del proyecto, defina la seguridad en la capa adecuada del sistema. Los posibles controles pueden incluir:

• Puertas de enlace autenticadas.

• Segmentación de la red.

• Acceso seguro al servicio.

• Autorización de mando.

• Firma de firmware.

• Arranque seguro.

• Comprobaciones de actualidad de los mensajes.

• Autenticación de la capa de aplicación.

• Control de acceso físico.

Los requisitos de seguridad deben incluirse en la arquitectura del equipo, no agregarse después de la integración del protocolo.

Qué incluir en una solicitud de cotización de batería RS485 o CAN

Proporcione al proveedor de baterías:

1. Tipo de equipo y modelo de controlador.

2. Interfaz física requerida.

3. Protocolo de red existente.

4. Velocidad en baudios o velocidad de bits CAN.

5. Requisito de identificador CAN estándar o ampliado.

6. Señales de batería requeridas e intervalos de actualización.

7. Comandos que el host debe enviar.

8. Conector y pinout.

9. Longitud del cable, topología y número de nodos.

10. Requisitos de aislamiento, puesta a tierra y blindaje.

11. Alarma, tiempo de espera y comportamiento de estado seguro.

12. Archivos de protocolo necesarios, herramientas de prueba y soporte de validación.

Si aún no se ha seleccionado el protocolo, proporcione la arquitectura de control y los requisitos de temporización en lugar de elegir una interfaz por costumbre.

Preguntas frecuentes

1. ¿CAN siempre es mejor que RS485 para un BMS de batería?

No. CAN ofrece funciones útiles de arbitraje, manejo de errores y comunicación distribuida, pero RS485 puede ser más simple y completamente adecuado para un sistema de monitoreo controlado por maestro. La elección correcta depende del equipo.

2. ¿Pueden dos dispositivos RS485 comunicarse automáticamente?

No. Deben utilizar velocidades de baudios, cableado y protocolos de aplicación compatibles. Tener puertos RS485 en ambos dispositivos no garantiza comandos o registros compatibles.

3. ¿Puede cualquier batería CAN funcionar con un controlador CAN?

No. Los dispositivos deben utilizar velocidades de bits, identificadores, definiciones de mensajes, temporizaciones y protocolos de capa superior compatibles.

4. ¿RS485 significa Modbus RTU?

No. Modbus RTU comúnmente usa RS485, pero RS485 también puede transportar protocolos propietarios u otros protocolos seriales.

5. ¿CAN significa CANopen?

No. CANopen es un protocolo de capa superior basado en CAN. Otros sistemas pueden utilizar J1939 o mensajes CAN propietarios.

6. ¿Qué interfaz es mejor para AGV y robots industriales?

CAN es común en maquinaria móvil distribuida, pero la respuesta depende de la red de controladores existente, la latencia, el diagnóstico y los recursos de integración. RS485 aún puede ser adecuado para un enlace de batería de supervisión independiente.

7. ¿Qué es un archivo DBC?

Un archivo DBC describe mensajes CAN, identificadores, señales, escalado e información relacionada. Puede ayudar al software y a las herramientas de diagnóstico a interpretar los datos CAN, pero no todos los proyectos CAN propietarios proporcionan uno.

8. ¿Se requiere terminación tanto para RS485 como para CAN?

Ambos suelen requerir una terminación controlada basada en el diseño de la red. La resistencia y ubicación correctas dependen de la interfaz, la topología y la implementación del transceptor.

9. ¿Debería aislarse la interfaz de comunicación?

El aislamiento depende de la conexión a tierra, la longitud del cable, las diferencias de voltaje, las condiciones EMC y la arquitectura de seguridad del sistema. El proveedor y el ingeniero del equipo deben evaluarlo juntos.

10. ¿Qué se debe probar antes de aprobar la batería?

Pruebe datos normales, sincronización, alarmas, comandos, inicio, suspensión y activación, tiempos de espera, reinicio del controlador, fallas de cables, tráfico elevado, funcionamiento del cargador y cargas representativas de la máquina.

Elija la arquitectura de comunicación antes de congelar la batería

El mejor momento para definir la comunicación RS485 o CAN es antes de que se congelen el gabinete de la batería, el conector y el software de control.

Comience con los requisitos de datos, sincronización y respuesta a fallas. Luego seleccione la interfaz física, la topología de la red y el protocolo de capa superior que coincidan con la arquitectura del equipo.

Documente cada registro o mensaje, pruebe la red completa y defina qué debe hacer la máquina cuando la comunicación deja de ser confiable.

Dailymag Energy admite la combinación personalizada de paquetes de baterías de litio para equipos industriales. Si su proyecto requiere RS485, CAN u otra interfaz de comunicación BMS, prepare la información del controlador, los requisitos del protocolo, la distribución de pines y la lista de datos requeridos antes de solicitar una propuesta.

Póngase en contacto con el equipo de ingeniería y ventas de Dailymag Energy para comenzar una revisión de comunicación específica del proyecto.