CAN, RS485 y CANopen: ¿Qué comunicación necesita una batería de robot?

A batería de robot necesita una interfaz y un protocolo de comunicación que coincidan con el controlador del robot, el cargador, los requisitos de datos BMS y la arquitectura de red. CAN funciona bien para la comunicación basada en prioridades entre múltiples nodos. RS485 proporciona una interfaz serie diferencial robusta y, a menudo, se combina con un protocolo de aplicación como Modbus RTU. CANopen agrega un marco de comunicación estandarizado de capa superior además de CAN.

No existe un método de comunicación único que todos los AGV o AMR deban utilizar. Para confiable batería de robot comunicación, la compatibilidad debe extenderse más allá del conector. La interfaz eléctrica, la velocidad de bits o baudios, la estructura del mensaje, el mapeo de datos, el direccionamiento, la sincronización, el comportamiento de fallas y la lógica de carga deben coincidir con el sistema host.

¿Qué necesita una batería de robot para comunicarse?

A batería de robot se comunica porque el robot necesita más que energía eléctrica. Su sistema de gestión de baterías debe poner a disposición de equipos como el controlador del vehículo, el cargador, la base de carga, la computadora de diagnóstico o la puerta de enlace de gestión de flotas las condiciones seleccionadas de la batería y los límites operativos.

Datos de la batería que necesita el robot

Un BMS de batería AMR mide o calcula varias categorías de información. Es posible que el controlador no necesite todos los valores de las celdas internas de manera continua, pero debe recibir los datos necesarios para la operación, carga, diagnóstico y mantenimiento.

Categoría de datos	Información típica	Cómo utiliza el robot it
Estado eléctrico	Voltaje del paquete, corriente, capacidad restante	Supervisa el estado actual de la batería.
Estado térmico y celular.	Voltaje de celda, temperatura del paquete, temperatura de la celda	Apoya las decisiones de protección y operación.
Estimaciones de batería	SOC, SOH	Admite planificación de tiempo de ejecución y mantenimiento
Límites operativos	Corriente de carga, corriente de descarga, voltaje de carga.	Ayuda a mantener la operación dentro de los límites de BMS
Datos de fallos y advertencias	Sobretensión, subtensión, sobretemperatura, sobrecorriente	Admite respuesta controlada a fallos
Estado del sistema	Carga, descarga, espera, estado de protección	Coordina el comportamiento del robot.
Identificación	Dirección del dispositivo, versión del protocolo, identidad de la batería.	Apoya el reconocimiento y el servicio.

Esto también es coherente con el moderno diseño BMS de robótica móvil. Las plataformas de referencia BMS orientadas a la robótica de NXP combinan medición de voltaje de celda y paquete, detección de corriente, detección de temperatura y conectividad CAN dentro de la misma arquitectura de administración de baterías.

Por lo tanto, la especificación de comunicación para una batería de robot debe comenzar con los datos que el robot necesita, en lugar de con un conector preferido o un nombre de bus.

SOC, SOH e informes de fallos

SOC le da al robot una estimación de la carga restante, mientras que SOH representa el estado de la batería a largo plazo. Ambos son valiosos, pero ninguno debe considerarse como un requisito de comunicación completo.

A batería de robot También puede informar temperaturas, corriente, estados de advertencia, condiciones de protección y límites de carga o descarga permitidos. Cuando las condiciones de operación cambian, estos valores brindan al controlador del vehículo información que puede usar antes de que el BMS alcance un estado de protección estricta.

Esto hace que la comunicación con la batería del robot sea útil tanto para la operación como para el mantenimiento inmediato. El software de flota puede utilizar información consistente sobre el estado y las fallas para distinguir una condición de baja energía de un evento térmico, un evento de protección o una falla de comunicación.

Apretones de manos del controlador y del cargador

El controlador del vehículo y el cargador no requieren necesariamente datos de batería idénticos. Durante el movimiento, el controlador puede priorizar SOC, voltaje, corriente, temperatura, advertencias y límites de descarga. Durante la carga, es posible que el sistema también necesite permiso de carga, límites de corriente de carga, límites de voltaje, estado de temperatura e información del estado de carga.

Por este motivo, especificar un BMS de batería CAN o un BMS de batería RS485 es sólo el primer paso. Dos dispositivos pueden compartir la misma interfaz eléctrica pero utilizar diferentes identificadores, registros, factores de escala, intervalos de actualización o lógica de control.

La carga automática hace que la distinción sea particularmente importante. Cuando un AGV o AMR se acopla sin la intervención del operador, la batería del robot, el cargador y el controlador necesitan un comportamiento definido para la autorización de carga, los límites operativos, el manejo de fallas, la finalización de la carga y el regreso al servicio.

Por qué la comunicación afecta el tiempo de actividad

La comunicación útil de la batería permite que el robot responda a las condiciones de la batería antes de que un apagado forzoso se convierta en la única respuesta disponible. Un SOC bajo puede iniciar una tarea de carga, una condición de temperatura puede afectar el comportamiento de carga y una falla reportada puede colocar el vehículo en un estado de servicio definido.

Para las flotas, los datos consistentes de las baterías de los robots también mejoran la resolución de problemas. Los equipos de mantenimiento pueden revisar los estados operativos y las alarmas en lugar de tratar cada pérdida de propulsión o interrupción de la carga como el mismo problema.

El beneficio no es simplemente más telemetría. El valor real proviene de hacer de la batería una parte integrada e interpretable de la arquitectura de control del robot.

CAN versus RS485: en qué se diferencian en los sistemas robóticos

CAN y RS485 son comunes en sistemas industriales, pero resuelven diferentes partes del problema de comunicación. CAN proporciona mecanismos de encuadre de mensajes, arbitraje, reconocimiento y gestión de errores para un bus compartido. RS485 define principalmente la señalización eléctrica utilizada para la comunicación en serie.

Esa distinción es importante cuando los ingenieros seleccionan una arquitectura de comunicación para una batería de robot.

CAN como red

CAN está diseñado para múltiples dispositivos que se comunican en un bus compartido. Los mensajes se identifican mediante identificadores CAN y los intentos de transmisión simultánea se resuelven mediante arbitraje basado en prioridades.

Para la comunicación de la batería del robot, esta arquitectura puede admitir mensajes de estado regulares, límites operativos, información de advertencia e informes de fallas basados ​​en eventos. El actual diseño de referencia BMS de robótica móvil MR-BMS771 de NXP incluye dos buses CAN, lo que proporciona un ejemplo práctico de CAN integrado directamente en una plataforma robótica de gestión de baterías.

Sin embargo, un puerto CAN por sí solo no define el significado de los datos. Un BMS de batería CAN y un controlador de robot aún necesitan velocidades de bits, identificadores, definiciones de carga útil, escalado, temporización de transmisión y lógica de aplicación compatibles.

RS485 como interfaz física

RS485 es una interfaz serie diferencial ampliamente utilizada en comunicaciones industriales multipunto. Es particularmente útil cuando el equipo ya utiliza redes seriales o cuando un controlador se comunica con múltiples dispositivos direccionados.

Para una batería de robot, el punto crítico es que RS485 por sí solo no le dice al controlador qué significa cada byte. Un BMS de batería RS485 todavía necesita un protocolo de aplicación definido o una estructura de datos patentada.

Esta distinción explica por qué RS485 y Modbus RTU frecuentemente aparecen juntos sin ser sinónimos. La organización Modbus documenta las implementaciones de la línea serie Modbus utilizando EIA/TIA-485, mientras que el propio Modbus define el comportamiento de mensajería de nivel superior.

Por lo tanto, una especificación de compra debería decir algo más que “Se requiere RS485”. Debe identificar el protocolo real y el mapa de datos que espera el robot.

CAN Arbitraje y Manejo de Errores

CAN permite que los nodos transmitan sin esperar a que un controlador central asigne cada oportunidad de transmisión. Si dos nodos comienzan a transmitir al mismo tiempo, el arbitraje basado en los identificadores de mensajes determina qué trama continúa.

CAN también incluye mecanismos para detectar errores de transmisión y gestionar nodos que generan errores repetidamente. Estas características lo hacen adecuado para redes donde el batería de robot debe intercambiar datos operativos frecuentes con otros controladores.

La decisión de ingeniería no debe reducirse a una afirmación genérica de que CAN es simplemente “más rápido”. Lo que importa es si los mensajes de batería requeridos se pueden entregar con la prioridad necesaria y el tiempo de actualización bajo la carga de bus esperada.

Para un robot móvil, un pequeño conjunto de mensajes de batería documentados y priorizados correctamente suele ser más valioso que una velocidad de datos teóricamente alta con un comportamiento de aplicación mal definido.

Modbus RTU sobre RS485

Modbus RTU proporciona una estructura de mensajería a nivel de aplicación que puede funcionar a través de un enlace serie RS485. El protocolo define cómo los dispositivos direccionados intercambian solicitudes y respuestas, mientras que el mapa de registro específico del equipo identifica dónde se almacenan los valores individuales.

Para una batería de robot, un mapa Modbus RTU puede contener registros de voltaje, corriente, SOC, temperatura, alarmas o límites de funcionamiento del paquete. La interpretación correcta requiere que el controlador conozca la dirección del registro, el formato de los datos, el factor de escala, el orden de los bytes, la dirección del dispositivo, la velocidad en baudios, la paridad y el comportamiento del tiempo de espera.

Varias distinciones son importantes durante la integración: RS485 no significa automáticamente Modbus RTU; dos dispositivos Modbus no utilizan automáticamente el mismo mapa de registro; un conector RJ45 no establece compatibilidad con Ethernet, CAN o RS485; y una conexión eléctricamente válida no garantiza la compatibilidad a nivel de aplicación.

Estas comprobaciones evitan un error de integración común: ambas partes parecen admitir la misma tecnología de comunicación, pero la batería del robot y el controlador no pueden entender los datos del otro.

Dónde encaja CANopen en un sistema de batería de robot

CANopen se encuentra encima de CAN en la pila de comunicaciones. No reemplaza al bus CAN. En cambio, CANopen define mecanismos estandarizados para organizar datos de dispositivos, transmitir información de procesos, acceder a parámetros de configuración, controlar los estados de la red y monitorear a los participantes de la red.

Por lo tanto, la implementación de una batería CANopen requiere más que un transceptor CAN o un conector CAN. El BMS tiene que implementar las funciones CANopen requeridas por el controlador host.

CAN no es CANopen

CAN proporciona el mecanismo de comunicación de red subyacente. CANopen agrega la estructura de capa superior que determina cómo los dispositivos basados ​​en CAN organizan e intercambian datos de aplicaciones.

CAN en Automatización, o CiA, describe un dispositivo CANopen con una pila de protocolos CANopen, software de aplicación y un diccionario de objetos que conecta el sistema de comunicación con los parámetros de la aplicación.

Esto hace que una regla de contratación sea especialmente importante:

La compatibilidad con CAN no significa automáticamente compatibilidad con CANopen.

Si un controlador AMR requiere una batería CANopen, la especificación debe identificar la funcionalidad CANopen y las asignaciones de datos esperadas por el controlador. No basta con solicitar un puerto CAN.

El diccionario de objetos CANopen

El diccionario de objetos es el modelo de datos estructurados utilizado por los dispositivos CANopen. CiA especifica que los parámetros de comunicación y aplicación se organizan a través de entradas de diccionario de objetos indexados, con valores de índice y subíndice que proporcionan direcciones definidas para los datos.

En una integración de batería CANopen, esta estructura puede proporcionar una forma consistente de exponer el estado de la batería, los parámetros de configuración y la información de diagnóstico. Los objetos reales de la batería aún deben coincidir con los requisitos del controlador y cualquier perfil aplicable o especificación del proyecto.

La ventaja práctica es la claridad. Los ingenieros no tienen que tratar cada trama CAN como un mensaje propietario aislado cuando se utiliza una implementación CANopen definida. Pueden trabajar con objetos documentados y servicios de comunicación.

PDO, SDO y diagnóstico

CANopen separa diferentes tareas de comunicación a través de servicios definidos. Los objetos de datos de proceso, o PDO, son adecuados para procesar la información intercambiada durante la operación. Los objetos de datos de servicio, o SDO, brindan acceso a entradas en el diccionario de objetos para funciones de configuración y servicio.

CANopen también proporciona mecanismos para informar errores y supervisar nodos. La documentación de CiA identifica las funciones PDO, SDO, emergencia, latido y administración de red como partes de la arquitectura de comunicación CANopen.

Para una batería CANopen, los valores operativos requeridos con frecuencia se pueden asignar a la comunicación PDO, mientras que el acceso SDO puede respaldar la puesta en servicio o el diagnóstico. El mapeo exacto debería acordarse antes de la integración, en lugar de asumirse.

Esta es también la razón por la que una batería de robot que se comunica exitosamente a través de CAN propietario no puede considerarse automáticamente compatible con CANopen.

Gestión de red y latidos

CANopen Network Management, o NMT, define los estados de comunicación de un dispositivo. CiA identifica los estados de inicialización, preoperacional, operativo y detenido dentro de la máquina de estados CANopen NMT. La comunicación PDO está disponible en el estado operativo, mientras que la comunicación SDO se puede utilizar en el estado preoperativo.

Para la comunicación de la batería del robot, estos estados ayudan a definir el comportamiento durante el inicio, la puesta en servicio, el funcionamiento normal, el apagado y la recuperación.

Los mecanismos de latido proporcionan otra función útil al permitir que el controlador determine si un nodo esperado permanece presente en la red. Por lo tanto, una especificación de batería CANopen debería cubrir más que los campos de datos de la batería. El estado de inicio, el tiempo de los latidos, la respuesta del tiempo de espera y el comportamiento de recuperación también pueden ser importantes para el robot.

Elegir la interfaz adecuada para AGV y AMR

El método de comunicación correcto es aquel que coincide con la arquitectura de control existente del robot y proporciona la información de la batería requerida por ese sistema.

Por lo tanto, la selección del protocolo debe comenzar con el controlador host y la arquitectura de carga en lugar de con una preferencia genérica por CAN o RS485.

Haga coincidir la red de robots existente

El primer paso es determinar exactamente qué espera el controlador del robot. Un controlador puede utilizar tramas CAN patentadas, CANopen, RS485 con Modbus RTU u otro protocolo documentado.

Arquitectura existente	Requisito apropiado de batería de robot
Controlador CAN propietario	Batería CAN BMS con velocidad de bits y mapa de mensajes coincidentes
Controlador CANopen	BMS que implementa los objetos CANopen requeridos y el comportamiento de la red
PLC o controlador mediante Modbus RTU	BMS de batería RS485 con configuración de serie coincidente y mapa de registro
Redes separadas de control y diagnóstico.	Definir qué conexión lleva control de batería y cuál lleva datos de servicio

La batería del robot debe adaptarse a ese requisito de red. Elegir un paquete porque su conector o etiqueta de puerto le resulta familiar invierte el proceso de ingeniería correcto.

Definir los datos de batería requeridos

Antes de solicitar un paquete personalizado, los ingenieros deben crear una matriz de comunicación que separe los datos necesarios para la operación de la información destinada principalmente al diagnóstico o mantenimiento.

Para muchos proyectos AGV y AMR, el requerido batería de robot los datos incluyen:

• Voltaje y corriente del paquete
• SOC y SOH
• Temperatura de la batería
• Límites de carga y descarga
• Estados de advertencia y protección
• Estado de carga y estado BMS
• Identidad del dispositivo o dirección de red
• Estado del contactor o MOSFET cuando lo requiera el sistema

El proyecto también debe definir la dirección de los datos. Parte de la información se transmite desde el BMS de la batería AMR al host, mientras que otras arquitecturas pueden requerir comandos de control, reconocimientos o mensajes de configuración del controlador.

Este paso determina lo que realmente debe lograr la interfaz.

Verifique el tiempo y la respuesta a fallas

Una especificación de comunicación completa necesita requisitos de temporización además de definiciones de datos.

Los ingenieros deben determinar con qué frecuencia se debe actualizar la información crítica de la batería del robot, cuánto tiempo espera el controlador antes de declarar el BMS fuera de línea y qué respuesta sigue a un tiempo de espera de comunicación. Las prioridades de los mensajes CAN o los intervalos de sondeo RS485 deben reflejar la importancia de los datos que se transfieren.

La recuperación de fallos también necesita un comportamiento definido. El sistema debe establecer si la comunicación se reanuda automáticamente después de un evento transitorio, si el BMS requiere un reinicio y si el robot puede reanudar la operación inmediatamente o debe verificar primero el estado de la batería.

Estas decisiones son específicas de la aplicación. Deben documentarse durante la integración en lugar de inferirse de la interfaz de comunicación.

Planificar la comunicación del muelle de carga

Un AGV o AMR cargado automáticamente necesita que la base de carga se considere parte del batería de robot arquitectura.

Es posible que el sistema de carga necesite coordinar el permiso de carga, el voltaje de la batería, los límites de corriente, el estado de temperatura, el estado de carga, la finalización y las condiciones de falla. Los contactos de carga físicos o un receptor de energía sin contacto proporcionan la ruta de energía, pero no definen el comportamiento de la comunicación.

El robot también necesita una secuencia clara para detectar la base, permitir la carga, responder a los límites del BMS, completar el proceso de carga y volver a funcionar.

La guía de integración AMR actual de MANLY Battery identifica la comunicación CAN o RS485, el monitoreo de corriente y temperatura, el diseño del conector y el cableado específico de la aplicación como factores a coordinar al integrar una batería AMR, un BMS y una base de carga.

Por lo tanto, para las flotas autónomas, la comunicación de carga debe diseñarse al mismo tiempo que la batería del robot y el BMS y no después de que el paquete ya esté finalizado.

Considere las necesidades de diagnóstico de la flota

Los datos de control de tráfico y mantenimiento no siempre necesitan utilizar la misma ruta de comunicación. Algunos robots colocan datos de la batería urgentes en la red CAN primaria mientras usan una interfaz separada para la puesta en servicio, el servicio o diagnósticos más profundos.

Lo que importa es que la arquitectura del diagnóstico sea deliberada.

Para flotas grandes, las definiciones consistentes de datos de baterías de robots pueden simplificar la resolución de problemas en muchos vehículos. Los códigos de falla, las unidades, la escala, las versiones de firmware, los estados de comunicación y los registros de mantenimiento deben tener significados repetibles de un robot a otro.

Esto puede resultar particularmente valioso cuando se utiliza software de flota para distinguir eventos relacionados con la energía de fallas de BMS, fallas del cargador o fallas de comunicación.

Qué preguntarle a un fabricante de baterías antes de la integración

A fabricante de baterías debería poder analizar la comunicación BMS con el mismo detalle de ingeniería utilizado para los requisitos de voltaje, capacidad, corriente, dimensiones y conectores del paquete.

“CAN disponible” o “RS485 disponible” es útil para la evaluación inicial, pero la batería de un robot de producción requiere una especificación de comunicación más completa.

Mapa de protocolo y mensajes

Para la integración CAN, solicite el protocolo de aplicación, los identificadores CAN, las definiciones de carga útil, la escala, la dirección del mensaje, el tiempo de transmisión y el comportamiento del tiempo de espera.

Para una batería CANopen, defina las entradas requeridas del diccionario de objetos, asignaciones de PDO, acceso a SDO, comportamiento NMT, requisitos de latido y funciones específicas del controlador.

Si el proyecto utiliza comunicación CAN específica del fabricante, la definición del mensaje debería estar disponible con suficiente antelación para el desarrollo del controlador y las pruebas en banco. El equipo de software no debería tener que aplicar ingeniería inversa al batería de robot después de que llegue el hardware prototipo.

Velocidad en baudios e ID de nodo

Ambos lados de la conexión deben utilizar configuraciones de red compatibles.

Para CAN, confirme la velocidad de bits de CAN y el identificador relevante o la configuración del nodo. Para CANopen, defina también los ID de nodo y el comportamiento de administración de red requerido. Para un BMS de batería RS485, confirme la velocidad en baudios, la paridad, los bits de parada, el direccionamiento y el comportamiento de respuesta o sondeo esperado.

Estos parámetros deben registrarse en la especificación de comunicación del proyecto y controlarse como cualquier otro requisito de interfaz a nivel del sistema.

Registro Escalado de mapas y datos

Una conexión RS485 mediante Modbus RTU necesita un mapa de registros completo. Cada valor requerido debe tener una dirección definida, tipo de datos, factor de escala, unidad de ingeniería y método de acceso.

Por ejemplo, un valor transmitido no se puede interpretar correctamente hasta que el controlador sepa si representa voltios, milivoltios, décimas de voltio, corriente con signo u otra codificación.

El mismo principio se aplica a CAN. Recibir una trama CAN válida no prueba que el batería de robot los datos han sido interpretados correctamente. El orden de los bytes, las definiciones de bits, la escala, los valores con signo y los indicadores de estado aún deben coincidir.

Terminación, distribución de pines y conectores

La documentación eléctrica debe identificar cada pin de comunicación requerido, incluidos CAN-H, CAN-L, RS485-A, RS485-B, señal de tierra, líneas de estela, blindaje u otros conductores específicos del proyecto.

La terminación también debe coincidir con la topología de red seleccionada. Los ingenieros deben verificar si la terminación está dentro de la batería del robot, instalada en otro lugar del robot, configurable u omitida.

La forma del conector nunca debe utilizarse como sustituto de esta documentación. Un conector estilo RJ45, por ejemplo, no indica automáticamente Ethernet y no establece una distribución de pines CAN o RS485 estandarizada.

Por lo tanto, el diseño del cable y del conector pertenece a las especificaciones de comunicación, no sólo al dibujo mecánico.

Requisitos de comunicación del cargador

La batería del robot y el cargador deben diseñarse como un sistema coordinado cuando el proceso de carga requiere comunicación.

La especificación debe definir si el cargador utiliza configuraciones eléctricas fijas o recibe límites dinámicos del BMS o del controlador del vehículo. También debe documentar la lógica de habilitación de carga, los límites de corriente y voltaje, el comportamiento térmico, el estado de carga, la finalización de la carga, la respuesta a fallas, el protocolo de enlace de la base y la recuperación después de una carga interrumpida.

Para un AGV o AMR que depende de la carga desatendida, estas funciones pueden afectar directamente la confiabilidad con la que el robot vuelve a funcionar después de llegar al muelle.

Opciones de comunicación de la batería MANLY

En MANLY Battery, los proyectos de robots y baterías industriales se pueden desarrollar en torno a los requisitos de comunicación de la aplicación en lugar de tratar la interfaz como un complemento aislado.

La batería del robot MANLY de 24 V y 50 Ah es un paquete LiFePO4 con una potencia nominal de 24 V, con un voltaje de batería real de 25,6 V y 1280 Wh de energía nominal. Su especificación actual proporciona comunicación opcional RS485, RS232 o CANBus. Las dimensiones, la carcasa, el conector, la caja y el cableado también se pueden configurar para los requisitos de OEM/ODM.

Para robots industriales que requieren mayor capacidad a bordo, la batería de robot MANLY 48V 100Ah proporciona 100Ah de capacidad y 4.800Wh de energía nominal. También admite comunicación opcional RS485, RS232 o CANBus, con dimensiones, carcasa, conectores y cableado personalizables.

Batería de robot MANLY	Comunicación	Enfoque de integración
Batería de robot LiFePO4 de 24V 50Ah	RS485, RS232, CANBus opcionales	Proyectos de robots y AGV que requieren comunicación BMS configurable, conectores y dimensiones del paquete
Batería de robot industrial de 48V 100Ah	RS485, RS232, CANBus opcionales	Aplicaciones de robots industriales de mayor capacidad que requieren integración coordinada de BMS, controlador, cargador y paquete

Si un proyecto requiere específicamente comunicación de batería CANopen, ese requisito debe definirse durante la revisión de ingeniería. La disponibilidad de CANBus por sí sola no debe considerarse como una confirmación de la compatibilidad con CANopen.

El equipo del proyecto debe proporcionar el mapeo de objetos CANopen requerido, la configuración de red, el comportamiento del controlador y otros requisitos de protocolo para que la implementación pueda evaluarse antes de comenzar. batería de robot el diseño está finalizado.

Para proyectos CAN o RS485, se aplica el mismo principio. Proporcionar la especificación del controlador, el mapa de mensajes o registros, la velocidad de comunicación, la configuración de pines, la arquitectura del cargador, el voltaje, la capacidad, los requisitos actuales y el comportamiento de falla esperado le brinda al fabricante de baterías un objetivo de integración mucho más claro.

El derecho comunicación de la batería del robot Por lo tanto, el método no se determina eligiendo CAN, RS485 o CANopen de forma aislada. Está determinado por si el BMS, el controlador del robot, el cargador, el cableado, el protocolo y la lógica operativa se han diseñado para funcionar juntos como un solo sistema.

Obtenga más información sobre la batería