Un proveedor de baterías no puede diseñar una interfaz CAN fiable a partir de una fotografía del conector y unas pocas tramas capturadas. Esta guía explica el paquete técnico exacto que un fabricante de equipo original (OEM) debe facilitar antes de que comience la integración del sistema de gestión de la batería (BMS) de las carretillas elevadoras.
Esto falla desde el principio.
Cuando un fabricante de carretillas elevadoras envía a un proveedor de baterías nada más que la tensión nominal, la capacidad, fotos de los conectores y una vaga petición de “hacer que CAN funcione”, el proyecto ya ha pasado de ser un proceso de ingeniería controlado a convertirse en una costosa ingeniería inversa, en la que cada suposición que falta se traduce en un nuevo retraso en el prototipo, una revisión del firmware o un fallo sobre el terreno.
¿Por qué las empresas de equipos de alta tecnología siguen considerando los datos de comunicación como algo opcional?
La integración del bus CAN en las baterías de las carretillas elevadoras no es una simple cuestión de cableado. Se trata de un acuerdo de interfaz entre el sistema de gestión de la batería, la unidad de control del vehículo, el cargador, el cuadro de instrumentos, el inversor de tracción, la unidad telemática y, en ocasiones, una ECU de pasarela.
El proveedor necesita algo más que CAN-H y CAN-L.
Debe saber qué significa cada mensaje, cuándo debe aparecer, a quién pertenece, qué ocurre cuando desaparece y qué dispositivo tiene la autoridad para detener la recarga o desactivar la tracción.
Mi opinión, sin rodeos, es sencilla: Un fabricante de equipos originales (OEM) que no facilite la definición de la interfaz no puede, razonablemente, responsabilizar al proveedor de la batería del rendimiento de la integración.
En Norma ISO 11898-1 sobre CAN define la capa de enlace de datos CAN y las reglas de codificación física. No define qué significa el byte 3 en una carretilla elevadora concreta, si el estado de carga utiliza una escala de 0,5%, ni si el mensaje 0x351 deben llegar cada 100 milisegundos.
Esa diferencia es importante.
Un proveedor puede conectar un analizador CAN y ver el tráfico de inmediato. Aparecen las tramas. Los contadores se incrementan. Los datos cambian cuando se acciona el acelerador o se conecta el cargador.
Pero el tráfico no es lo importante.
Fíjate en este fotograma:
ID CAN: 0x351
DLC: 8
Datos: 64 0A 5E 10 00 03 7B 92
Ciclo: 100 ms
Sin una definición de señal aprobada, el proveedor no sabe si:
Las conjeturas pueden dar lugar a un panel de control que funcione en el laboratorio, pero no garantizan una batería apta para la producción.
La diferencia entre una demostración de CAN y un producto integrado radica en la documentación.
El proveedor necesita un único paquete técnico bien organizado. No diez hilos de correo electrónico. No capturas de pantalla de una herramienta de servicio obsoleta. Y, desde luego, tampoco un archivo DBC en el que la mitad de las señales se llamen Reservado.
Este es el paquete mínimo de entrega que exigiría antes de aprobar la integración del sistema de gestión de baterías (BMS) de la carretilla elevadora.
| Entrega del fabricante de equipos originales (OEM) | Contenido obligatorio | ¿Por qué lo necesita el proveedor? | Error habitual cuando falta |
|---|---|---|---|
| Arquitectura de red | Todas las ECU conectadas, pasarelas, puntos de terminación, segmentos de bus, puertos de diagnóstico y propiedad de la red | Muestra dónde se encuentra la batería y qué controladores dependen de sus datos | La batería funciona en el banco de pruebas, pero falla al pasar por la puerta de acceso del vehículo |
| Especificación de la capa física | CAN Classic o CAN FD, identificadores de 11 o 29 bits, 250/500 kbps u otra velocidad de transmisión, punto de muestreo, terminación y circuitos de activación | Permite una comunicación eléctrica estable | Eventos de desconexión del bus, reflexiones, fallos intermitentes de arranque |
| DBC, EDS o una base de datos equivalente | Identificadores de mensajes, señales, posiciones de bits, escalado, desplazamientos, unidades, orden de los bytes, valores válidos y velocidades de transmisión | Proporciona la correspondencia de mensajes CAN de la batería de la carretilla elevadora | SOC incorrecto, corriente inversa, falsas alarmas de temperatura |
| Matriz de titularidad de los mensajes | ECU emisora, ECU receptora, tiempo de ciclo previsto, tiempo de espera y retardo de arranque para cada mensaje | Evita la duplicación de identificadores y los conflictos de sincronización | Dos dispositivos transmiten el mismo identificador o caducan los mecanismos de vigilancia |
| Máquina de estados de funcionamiento | Transiciones entre los estados de reposo, activación, espera, precarga, funcionamiento, carga, fallo, mantenimiento y apagado | Define el comportamiento legal en lugar de señales aisladas | Los contactores se abren durante el recorrido o permanecen cerrados durante una avería |
| Interfaz de carga | Identificadores de cargadores, solicitudes de tensión/corriente, lógica de activación del cargador, reducción de potencia, finalización de la carga y comportamiento en caso de tiempo de espera agotado | Coordina el sistema de gestión de la batería (BMS), el cargador y el camión | El cargador no arranca o no respeta el límite de corriente de la batería |
| Matriz de reacción ante fallos | Gravedad de la avería, nivel de advertencia, respuesta de par, respuesta del contactor, condiciones de recuperación y reglas de enclavamiento | Adapta el comportamiento del camión a la protección del sistema de gestión de la batería (BMS) | Las advertencias menores desactivan la tracción o se ignoran los fallos graves |
| Esquema de la interfaz eléctrica | Disposición de pines, modelo de conector, entrada de encendido, bucle de enclavamiento, alimentación auxiliar, apantallamiento y puesta a tierra | Evita daños en las comunicaciones y en el hardware | Línea de estela invertida, desplazamiento respecto al suelo, fallo en el enclavamiento |
| Especificaciones de diagnóstico | Identificadores de diagnóstico, UDS o servicios propios, formato DTC, derechos de acceso y método de actualización del firmware | Ofrece apoyo en las pruebas de producción y en el servicio técnico sobre el terreno | Los distribuidores no pueden detectar averías ni actualizar las baterías de recambio |
| Consultar los registros CAN | Arranque en frío, conducción normal, bajo nivel de carga (SOC), carga, carga completa, fallos y registros de apagado | Proporciona al proveedor pruebas de un comportamiento que se sabe que es adecuado | Los errores en la documentación permanecen ocultos hasta que se realizan las pruebas con el camión |
| Matriz de pruebas de aceptación | Condiciones de aprobación/suspenso, modelos incluidos, límites ambientales y versiones de software | Define cuándo se ha completado la integración | Revisiones interminables porque nunca se definió qué se entendía por “funcionar” |
El DBC es importante.
Sin embargo, una base de datos DBC suele describir mensajes y señales; rara vez recoge la máquina de estados completa de la batería, la secuencia de contactores, el modelo de ciberseguridad, los permisos de diagnóstico o la respuesta del vehículo ante la pérdida de comunicación, por lo que el fabricante de equipos originales (OEM) también debe elaborar un documento de control de interfaces y un plan de aceptación.
CoreSpark Capacidades de ingeniería de baterías OEM/ODM Ya abarcan la configuración personalizada del BMS, las opciones de comunicación, el diseño de conectores, la adaptación de los cargadores, el desarrollo de muestras y el apoyo en las pruebas. Ese flujo de trabajo solo resulta eficiente cuando el fabricante de equipos originales (OEM) proporciona datos de interfaz controlados desde el principio, en lugar de hacerlo después de que falle el primer prototipo.
Un archivo DBC del bus CAN válido para los proveedores de baterías debe definir todas las señales que la batería transmite o recibe.
Como mínimo, cada entrada de señal debe incluir:
La descripción de la suma de comprobación merece una atención especial. No basta con escribir “CRC-8”.
El proveedor necesita el polinomio, el valor inicial, el valor XOR final, las reglas de reflexión, el rango de bytes protegidos, las reglas de inclusión de identificadores, la posición del contador de actividad y un ejemplo verificado de entrada-salida. Tanto el CRC-8/SAE-J1850 como el CRC-8/AUTOSAR son cálculos de ocho bits, pero no son intercambiables.
Un parámetro que falte puede hacer que se pierdan días.
Y no, un trazo CAN no es un sustituto. Un trazo puede confirmar el comportamiento, pero rara vez revela todos los valores reservados, las condiciones de fallo, los tiempos de espera, las reglas de escalado, las semillas de suma de comprobación o las variantes específicas del modelo.
El fabricante de equipos originales debe identificar el protocolo de capa superior real.
Un sistema CAN propietario suele necesitar un archivo DBC y un documento de control de interfaz. Una implementación de CANopen puede requerir un archivo EDS o DCF, un diccionario de objetos, una asignación de PDO, un comportamiento SDO, estados NMT, tiempos de latido, reglas de identificación de nodos y definiciones de mensajes de emergencia.
En Perfil del dispositivo CiA 418 Se creó específicamente para facilitar la interoperabilidad entre los módulos de batería CANopen y los cargadores, incluidos los cargadores diseñados según la norma CiA 419. Se trata de una orientación útil, pero el hecho de que un producto sea “compatible con CANopen” no indica al proveedor qué objetos opcionales, asignaciones, identificadores de nodo o reglas de sincronización utiliza realmente la carretilla elevadora.
Un camión basado en el estándar J1939 necesita su propio conjunto de parámetros: PGN, SPN, direcciones de origen, comportamiento de reclamación de direcciones, PGN propios, frecuencias de repetición, requisitos del protocolo de transporte y normas de gestión de la red.
“Utiliza CAN” no nos dice prácticamente nada.
La mayoría de los problemas de integración no se producen mientras el camión circula con normalidad. Se producen durante las transiciones.
Activación. Precarga. Conexión del cargador. Retardo tras apagar el motor. Parada de emergencia. Apagado por baja tensión. Recuperación de la comunicación.
El fabricante de equipos originales debe documentar cada transición como una secuencia, y no como una lista inconexa de señales.
Una secuencia de arranque simplificada podría ser algo así:
Ahora haz las preguntas incómodas.
¿Qué ocurre si la solicitud del vehículo llega antes de que el BMS haya completado la autocomprobación? ¿Cuánto tiempo puede durar la precarga? ¿Debe el BMS recibir tres tramas válidas antes de cerrar los contactores? ¿Qué porcentaje del enlace de CC se considera que la precarga está completa: 85%, 90% o 95%? ¿Qué ocurre si la señal de presencia del vehículo desaparece durante 500 milisegundos mientras el camión está en movimiento?
Las respuestas no pueden surgir de la imaginación del proveedor de baterías.
Para cada estado de funcionamiento, el fabricante de equipo original (OEM) debe definir:
La misma disciplina se aplica al sueño.
Algunos camiones cortan la alimentación del encendido de inmediato. Otros esperan a que la batería permanezca activa durante 10, 30 o 120 segundos para que el vehículo pueda registrar datos de funcionamiento, transmitir mensajes finales o completar las cargas de datos telemáticos.
Una batería que entra en modo de reposo demasiado pronto puede parecer defectuosa, aunque su sistema de protección funcione perfectamente.
Muchos equipos hablan del camión y de la batería, mientras que consideran el cargador como un accesorio.
Eso es un error.
En un sistema integrado de carretillas elevadoras de litio, es posible que el cargador tenga que recibir:
Es posible que la batería también necesite información sobre la tensión de salida del cargador, la corriente disponible, el estado del cargador, los códigos de error y el estado del conector.
A continuación, el camión puede situarse sobre ambos dispositivos y determinar si se permite la recarga en función del estado del freno de mano, la posición de la llave, el estado del sistema de bloqueo, la presencia del operador, la detección del conector o las normas de funcionamiento del almacén.
¿Quién está al mando?
El fabricante original debe responder a ello por escrito.
CoreSpark soluciones para baterías de carretillas elevadoras abarcan el diseño de las zonas de recarga, la recarga ocasional, el dimensionamiento en función de los turnos, la seguridad y la planificación de la conversión. Estos temas están directamente relacionados con la integración de CAN, ya que un protocolo adecuado para las baterías de litio de las carretillas elevadoras debe ser compatible con la estrategia de recarga real, y no limitarse a mostrar el estado de carga (SOC) en una pantalla.
Una carretilla elevadora comercializada como “carretilla elevadora de 48 V” puede utilizar un paquete de baterías de litio con una arquitectura LFP de 51,2 V nominales. Una configuración típica de LiFePO₄ de 16 series utiliza celdas con una tensión nominal de aproximadamente 3,2 V, pero al controlador de la carretilla le importa el rango de funcionamiento completo, no la etiqueta comercial.
El fabricante de equipos originales debe proporcionar:
A continuación, el proveedor compara esos límites con las características químicas de las celdas, el recuento de series, los umbrales de protección del BMS y los ajustes del cargador.
Limitarse a hacer coincidir la palabra “48 V” no es ingeniería.
Una matriz de fallos debe relacionar cada estado de la batería con una respuesta concreta del vehículo.
Por ejemplo:
| Incidente con la batería | Funcionamiento de la batería | Actividad prevista de camiones | Regla de recuperación |
|---|---|---|---|
| Aviso del SOC | Transmitir el estado de alerta | Mostrar advertencia; mantener la tracción | Supera el umbral de SOC del fabricante original |
| Límite de SOC bajo | Reducir el límite de corriente de descarga | Reduce el par de forma gradual | Se apaga tras la carga |
| Sobretemperatura celular | Corriente de reducción | Limitar la tracción y la regeneración | Se desactiva una vez que se alcanzan los límites de temperatura e histéresis |
| Sobrecalentamiento grave | Abre los contactores cuando sea seguro hacerlo. | Introducir una parada controlada | Se requiere una revisión o un reinicio específico |
| Tiempo de espera de la red CAN mientras el vehículo está aparcado | Mantener o abrir los contactores según la lógica de estado | Mostrar fallo de comunicación | Recuperación tras una secuencia de tramas válidas |
| Tiempo de espera de CAN durante el desplazamiento | Aplicar el periodo de funcionamiento en caso de fallo acordado | Reducir el par o detenerse de forma segura | Procedimiento de reinicio definido por el fabricante original (OEM) |
| Fallo de aislamiento | Bloquear la unidad o la recarga | Mostrar códigos DTC de alta gravedad | Se requiere una inspección realizada por personal cualificado |
| Detección de contactores soldados | Impedir el reinicio normal | Desactivar el fallo del camión y del registro | Solo restablecimiento del servicio |
“Enviar un bit de fallo” no es una estrategia de gestión de fallos.
El fabricante de equipos originales (OEM) debe definir qué hace el vehículo tras recibirlo. El proveedor debe definir qué hace el sistema de gestión de la batería (BMS) si el vehículo no le hace caso.
Este segundo caso suele evitarse en las reuniones porque plantea cuestiones relacionadas con la autoridad. No obstante, hay que dar respuesta a ello.
El informe de lesiones graves de la OSHA correspondiente a 2024 registró 5.186 lesiones graves relacionadas con carretillas elevadoras entre 2015 y 2024, o más o menos nueve lesiones graves a la semana entre los empleadores incluidos en la base de datos federal. El informe también advierte de que la base de datos solo abarca una parte de la población activa de EE. UU., por lo que no debe considerarse un recuento nacional completo. Lee el Informe sobre lesiones graves de la OSHA de 2024.
No todas esas lesiones tuvieron que ver con baterías o fallos de comunicación. Esa no es la cuestión.
La cuestión es que las carretillas elevadoras operan en entornos con peatones, estanterías, muelles de carga, cargas elevadas y pasillos estrechos. Una interrupción inexplicable de la tracción, un cálculo incorrecto del nivel de carga (SOC), un límite de regeneración desactivado o la apertura de un contactor no suponen simplemente una mala experiencia para el usuario.
Puede afectar al funcionamiento seguro.
El texto normativo también es directo. En virtud de OSHA 29 CFR 1910.178(a)(4), las modificaciones que afecten a la capacidad o al funcionamiento seguro de una carretilla industrial motorizada requieren la autorización previa por escrito del fabricante, así como las correspondientes actualizaciones de las placas, etiquetas o adhesivos.
Por eso, cualquier programa de conversión al litio debería comenzar con el lista de comprobación para la conversión de carretillas elevadoras de plomo a litio y el proceso de autorización por escrito del fabricante de equipo original (OEM). La integración del sistema CAN no exime de tener en cuenta aspectos mecánicos relacionados con el peso de la batería, su fijación, las dimensiones del compartimento, el lastre, los conectores y la capacidad nominal.
En Normas sobre el peso de las baterías de las carretillas elevadoras y el contrapeso son especialmente relevantes en este caso. Una interfaz CAN técnicamente perfecta no puede corregir un paquete de recambio que incumpla el rango de peso de la batería homologado para el camión.
Las baterías conectadas son unidades de control electrónico (ECU) controladas por software.
Trátalos así.
La batería puede ofrecer acceso a funciones de diagnóstico CAN, Bluetooth, RS485, USB, software de servicio, datos telemáticos o actualización de firmware. Cada interfaz modifica el modelo de riesgo.
En Directrices de la NHTSA sobre ciberseguridad de los vehículos recomienda comunicar a los proveedores normas claras de ciberseguridad, mantener registros de los componentes y versiones del software, someter los productos a pruebas, documentar las decisiones de diseño, proteger el acceso a los diagnósticos, autenticar los mensajes relacionados con la seguridad siempre que sea posible y utilizar la segmentación o el filtrado de la red. Aunque el documento se centra en los vehículos de carretera, la lógica de ingeniería se aplica directamente a los equipos industriales conectados a la red CAN.
Existe un precedente real que justifica que nos tomemos esto en serio.
En julio de 2015, Fiat Chrysler retiró del mercado aproximadamente 1,4 millones de vehículos estadounidenses después de que unos investigadores demostraran que era posible acceder de forma remota a los controles de los vehículos conectados a la red a través del sistema Uconnect. Reuters informó de que los investigadores podían enviar órdenes que afectaban al motor, la dirección y los frenos.
Una batería de carretilla elevadora no es un Jeep Cherokee. Pero las redes CAN comparten una característica preocupante: una vez que una interfaz no fiable accede a un bus de control mal segmentado, una pequeña función de comunicación puede convertirse en una vía de acceso a funciones relacionadas con la seguridad.
Por lo tanto, el fabricante de equipos originales debe definir:
La seguridad basada en la opacidad de los conectores no es seguridad.
Hay casos justificados en los que un fabricante de equipos originales (OEM) antiguo no puede proporcionar la documentación completa. Es posible que el proveedor original del controlador ya no exista. Es posible que la base de datos DBC esté incompleta. Es posible que la plataforma del camión haya acumulado quince años de cambios de firmware no documentados.
La ingeniería inversa puede ser de ayuda.
Pero debe abordarse como un proyecto de ingeniería controlado con sus limitaciones, y no como un sustituto barato de la colaboración con los fabricantes de equipos originales.
Un programa de ingeniería inversa adecuado puede requerir:
Aun así, es posible que algunas condiciones nunca aparezcan en los datos capturados. Es posible que, durante la observación normal, no se produzcan fallos graves de aislamiento, eventos de contactores soldados, fallos del sensor de temperatura de la celda, recuperaciones del gestor de arranque o errores poco frecuentes del cargador.
El silencio no es una prueba.
El mejor enfoque consiste en utilizar trazas CAN grabadas para verificar la especificación escrita. Cuando la traza y el documento no coinciden, el fabricante de equipos originales debe resolver la discrepancia y publicar una definición revisada, sujeta a control de versiones.
Un programa serio de integración de baterías OEM requiere una matriz de aceptación firmada.
Las pruebas deben abarcar algo más que “el arranque y la conducción del camión”.”
Comprueba:
Prueba:
Desconectar o simular:
A continuación, comprueba que la batería, el camión, el cargador y la pantalla respondan todos según la misma matriz de averías.
No se debe pedir a un proveedor que averigüe cuál es el criterio de aceptación durante la prueba final del vehículo. Eso es una «contratación por sorpresa».
CoreSpark Estudios de caso y proceso de validación del proyecto de baterías de LiFePO₄ Hacer hincapié en la revisión de las muestras antes de la producción en serie, incluyendo la tensión, la capacidad, las dimensiones del paquete, la configuración del BMS, el método de carga y los requisitos de los conectores. En el caso de los proyectos de carretillas elevadoras con CAN integrado, esta misma fase debe incluir pruebas de conformidad con el protocolo y de fallos a nivel del vehículo antes de que se fije el firmware de producción.
Los fabricantes de equipos originales suelen mostrarse reacios a publicar una base de datos CAN completa, ya que contiene señales propias que no guardan relación con la batería.
Esa preocupación es razonable. La respuesta habitual, en cambio, no lo es.
El fabricante de equipos originales (OEM) no tiene por qué facilitar todas las señales de dirección, hidráulicas, de tracción o telemáticas. Debe facilitar la información suficiente para que el proveedor de baterías pueda implementar y verificar de forma segura la interfaz que se le haya asignado.
Existen tres modelos viables:
El fabricante de equipos originales (OEM) proporciona una base de datos filtrada que contiene la batería, el cargador, la pasarela y los mensajes de diagnóstico necesarios. Las señales no relacionadas se eliminan o se renombran.
El fabricante de equipos originales (OEM) proporciona un documento controlado en el que se definen únicamente las señales, las secuencias, los tiempos, los fallos y los servicios de diagnóstico que requiere la batería.
El fabricante de equipos originales (OEM) mantiene el protocolo del vehículo privado detrás de una pasarela y proporciona al proveedor de baterías una interfaz estable y documentada. Esto suele suponer la separación más clara a largo plazo, siempre que se especifiquen detalladamente los tiempos de espera y el comportamiento ante fallos de la pasarela.
Un acuerdo de confidencialidad puede proteger la información confidencial.
No puede sustituir a la información técnica.
Suspendería el proyecto de ingeniería si un fabricante de equipo original (OEM) dijera cualquiera de las siguientes cosas:
Esta última afirmación resulta especialmente peligrosa. Podría significar que el proveedor anterior disponía de una mejor documentación, incorporó una solución alternativa no documentada o asumió un riesgo de integración que nunca se ha evaluado formalmente.
El silencio en el pasado no es prueba de que la interfaz funcione correctamente.
La integración del bus CAN en las baterías de las carretillas elevadoras es el proceso de ingeniería mediante el cual se consigue que el sistema de gestión de la batería, el controlador de la carretilla, el cargador, la pantalla y las herramientas de diagnóstico intercambien mensajes definidos, sigan el mismo estado de funcionamiento y reaccionen de forma segura ante los límites, las averías, las órdenes de activación, las solicitudes de carga y la pérdida de comunicación.
El trabajo incluye la configuración de la capa física, la asignación de señales, la sincronización de mensajes, la lógica de los contactores, el control de la carga, los diagnósticos, la gestión del software y la validación a nivel del vehículo. Solo se considerará completado cuando tanto el funcionamiento normal como el comportamiento en caso de fallo cumplan los criterios de aceptación establecidos por escrito.
Un archivo DBC de bus CAN es una base de datos legible por ordenador que define todas las tramas y señales CAN que el proveedor debe implementar, incluidos los identificadores de mensajes, las posiciones de los bytes, las longitudes de bits, el orden de los bytes, el escalado, los desplazamientos, las unidades, las velocidades de transmisión, las reglas de multiplexación, los rangos válidos y, en ocasiones, las tablas de valores o los campos de suma de comprobación.
El DBC es solo una parte de la interfaz. Debería existir una especificación independiente que definiera las transiciones de estado, la coordinación con el cargador, las reacciones ante fallos, el comportamiento ante tiempos de espera agotados, los diagnósticos, los controles de ciberseguridad y las pruebas de aceptación.
El fabricante de equipo original (OEM) debe facilitar al proveedor de la batería el contrato de interfaz completo: disposición de los pines eléctricos, ajustes de la capa física, DBC o mapa de señales equivalente, propiedad de la red, sincronización de mensajes, transiciones de estado, protocolo de carga, reacciones ante fallos, acceso al diagnóstico, normas sobre versiones de software, trazas de prueba y criterios de aceptación por escrito para el modelo de carretilla elevadora en cuestión.
El fabricante de equipo original (OEM) también debe identificar todos los modelos incluidos, la versión del controlador, la versión del cargador y la variante regional. Un protocolo validado en una carretilla de 48 V no debe aplicarse automáticamente a toda una familia de productos.
La batería de una carretilla elevadora solo puede funcionar sin comunicación CAN cuando tanto la carretilla como el cargador se han diseñado para admitir una batería autónoma cuyo sistema de gestión de la batería (BMS) controle los contactores y los mecanismos de protección de forma independiente; en muchas carretillas elevadoras modernas, la ausencia de mensajes CAN provocará el activamiento de enclavamientos, el modo de funcionamiento limitado, el rechazo de la carga, la aparición de códigos de advertencia o la pérdida total de tracción.
Incluso una batería independiente debe ajustarse al rango de tensión del vehículo, a la demanda de corriente, al conector, a los requisitos de peso de la batería, al sistema de carga y a los controles de seguridad. Que “no se requiera CAN” no significa que sea “compatible sin modificaciones”.”
La mejor práctica de integración de CAN en baterías para carretillas elevadoras consiste en fijar una especificación de interfaz sometida a control de versiones, validarla con trazas CAN reales y mediante un sistema «hardware-in-the-loop» o un banco de pruebas para carretillas, simular tiempos de espera y fallos de sensores, confirmar el comportamiento del cargador y firmar una matriz de aceptación antes de que el proveedor lance el firmware de producción.
El fabricante de equipo original (OEM) y el proveedor también deben garantizar la trazabilidad de las versiones de los protocolos, revisar cada modificación del firmware, controlar el acceso a los diagnósticos y conservar las pruebas de cada combinación aprobada de carretilla elevadora, batería y cargador.
La documentación UN 38.3 no es un requisito del protocolo CAN; se trata de una prueba de conformidad con la normativa de transporte que demuestra que el diseño de una célula o batería de litio ha superado las pruebas correspondientes recogidas en la Parte III, subsección 38.3, del Manual de Ensayos y Criterios de las Naciones Unidas antes de ser puesta a disposición para su transporte.
En Administración de Seguridad de Oleoductos y Materiales Peligrosos de EE. UU. establece que los fabricantes y los distribuidores posteriores deben facilitar los resúmenes de las pruebas de las baterías de litio de conformidad con la normativa aplicable. Tanto la validación del protocolo como la documentación de transporte deben incluirse en el paquete de lanzamiento del proyecto, pero tienen finalidades diferentes.
No empieces un proyecto de integración del bus CAN de la batería de una carretilla elevadora basándote únicamente en el voltaje, los amperios-hora y una fotografía del conector.
Prepara la arquitectura de red, el archivo DBC o EDS, la matriz de propiedad de mensajes, la máquina de estados de funcionamiento, el protocolo de comunicación para la recarga, la tabla de respuesta a fallos, la disposición de los pines, los trazos CAN de referencia, la lista de versiones de software y los criterios de aceptación. Identifica los modelos exactos de camiones y cargadores implicados.
A continuación, envía el paquete para que se someta a una revisión técnica.
Un proveedor de baterías cualificado puede proteger los archivos confidenciales mediante un acuerdo de confidencialidad (NDA), señalar la información que falte, proponer un sistema de gestión de la batería (BMS) y una arquitectura de comunicación, construir un prototipo controlado y validar el resultado con el vehículo real.
Pero el proveedor no puede crear información que el fabricante de equipos originales nunca haya hecho pública.
Comparte con CoreSpark Battery el modelo de tu carretilla elevadora, el voltaje y la capacidad de la batería, el protocolo CAN, los detalles del cargador, el esquema del conector y la cantidad prevista para iniciar una revisión documentada de la integración OEM, en lugar de otra apuesta arriesgada basada en la ingeniería inversa.
