Sistema de control y Gemelo Digital en grúas
Más que fabricar grúas: la lógica técnica detrás del sistema de control y la plataforma de Gemelo Digital desarrollados por Kelude. En la industria de fabricación de grúas, los sistemas de control y las plataformas digitales se están convirtiendo en el factor decisivo que determina la competitividad de un producto.
En la industria de fabricación de grúas, los sistemas de control y las plataformas digitales se están convirtiendo en el factor decisivo que determina la competitividad de un producto. Mientras la mayoría de las empresas todavía recurren a la solución "estándar" de un PLC genérico combinado con un HMI de terceros, Kelude Industrias Pesadas ha optado por una ruta tecnológica completamente diferente: desde el hardware de bajo nivel hasta los algoritmos de alto nivel, desde la adquisición de datos hasta el Gemelo Digital, todo se desarrolla internamente. No se trata de mejorar la lista de proveedores, sino de que las soluciones genéricas presentan un techo de rendimiento inherente cuando se enfrentan a las complejas condiciones de operación de una grúa.
Este artículo desglosa la lógica técnica de la solución propia de Kelude en tres niveles: la arquitectura integrada de hardware y software del sistema de control, la capacidad de modelado y predicción de la plataforma de Gemelo Digital, y el esquema de integración de la plataforma de datos. En cada etapa, se realizará una comparación horizontal con las soluciones genéricas en términos de coste, rendimiento y escalabilidad.
Sistema de control propio: IPC + Linux en tiempo real + algoritmos propios para sustituir al PLC genérico
Plataforma de Gemelo Digital: Unity 3D + WebGL, modelo reducido POD y predicción con LSTM
La plataforma de Gemelo Digital de Kelude no existe para "mostrar efectos 3D". Su valor central reside en tres capacidades: visualizar con claridad, calcular con precisión y predecir con antelación. La lógica subyacente de la plataforma se puede resumir en un bucle cerrado: "datos → modelo → inferencia → decisión".
Capa de visualización: interacción WebGL basada en Unity 3D. Kelude ha elegido Unity 3D como motor de renderizado 3D y compila las escenas a formato WebGL. De este modo, los usuarios pueden acceder al modelo digital tridimensional completo de la grúa a través de un navegador, sin necesidad de instalar ningún software cliente. Este modelo no es una simple visualización CAD: refleja en tiempo real todos los estados de movimiento del equipo: la posición de traslación del puente, la posición del carro, la Altura de Elevación y el ángulo de oscilación de la carga. Todos estos datos se envían desde la plataforma de datos al front-end mediante WebSocket, con una frecuencia de actualización de 20 fps (resolución de 50 ms) y una latencia visual inferior a 100 ms. El operador, desde la sala de Control desde tierra, abre el navegador y ve una escena tridimensional idéntica a la de la Cabina de Mando.
Para garantizar una carga rápida de la escena 3D en el navegador, el equipo de I+D ha realizado una serie de optimizaciones de rendimiento: el número de polígonos del modelo se ha reducido de los 8 millones del CAD original a 150.000 (conservando todas las características exteriores y eliminando los detalles internos invisibles), las texturas utilizan el formato comprimido KTX2 para reducir el uso de memoria de vídeo, el controlador de animación emplea un patrón de máquina de estados en lugar de animación fotograma a fotograma, y la carga del primer fotograma se controla en menos de 4 segundos (en condiciones de red de 100 Mbps).
Capa de inferencia física: el modelo reducido POD resuelve el desafío de la simulación en tiempo real. La mayor dificultad técnica de un Gemelo Digital no es "parecerse", sino "calcular rápido". Un modelo de elementos finitos típico de la Viga Principal de un Puente Grúa de 100 toneladas puede tener más de 300.000 grados de libertad. Resolver un caso estático con software FEA comercial (como ANSYS o Abaqus) puede llevar de 3 a 5 minutos, algo totalmente inaceptable para una inferencia en tiempo real.
La solución adoptada por el equipo de Kelude es el modelo reducido POD (Proper Orthogonal Decomposition, o descomposición ortogonal propia). La idea central es sencilla: la distribución de Tensión de la estructura en la gran mayoría de las condiciones de operación puede aproximarse mediante una combinación lineal de un número reducido de "modos base". El equipo de I+D calculó previamente con ANSYS la respuesta de Tensión de campo completo para 1000 condiciones de operación típicas (diferentes posiciones y magnitudes de Carga, diferentes posiciones del carro). A continuación, mediante la descomposición en valores singulares (SVD), se extrajeron los primeros 15 modos base con mayor energía. Estos 15 modos base acumulan el 99,2% de la energía total, lo que significa que con 15 funciones base se puede reconstruir la gran mayoría de la información de las 1000 condiciones.
En tiempo de ejecución, el sistema solo necesita interpolar y combinar linealmente en el espacio de 15 dimensiones según las condiciones de Carga medidas en tiempo real. El tiempo de cálculo de un campo de tensiones se reduce a 15-30 ms, con un control de pérdida de precisión inferior al 5%. Esto permite que el sistema de Gemelo Digital siga cada operación de Izaje de la grúa y actualice en tiempo real el mapa de calor del campo de tensiones completo de la Viga Principal. El operador ya no ve valores aislados de puntos de medición de deformación en la pantalla, sino una vista panorámica de "dónde se aplica la fuerza y dónde se acumula la Fatiga" en toda la viga.
Datos de implementación real: en 3 Puentes Grúa de 100 toneladas, se instalaron 16 puntos de medición de deformación por fibra óptica (FBG) y 4 puntos de medición de aceleración en cada uno, con una frecuencia de adquisición de datos de 1 Hz. El modelo POD completa una inferencia del campo de tensiones completo cada segundo y superpone el resultado en el modelo Unity 3D. El sistema ha estado en funcionamiento continuo y estable durante más de 14 meses (hasta junio de 2026), acumulando más de 37 millones de inferencias sin una sola divergencia del modelo o anomalía en los resultados de cálculo.
Capa de predicción: modelo de series temporales LSTM para la predicción de vida útil restante. La capacidad de nivel superior de un Gemelo Digital no es "entender el presente", sino "anticipar el futuro". Sobre los datos del campo de tensiones generados por el modelo reducido POD, Kelude ha integrado un módulo de predicción de la vida a fatiga basado en LSTM (Long Short-Term Memory, o memoria a largo plazo).
Las características de entrada del modelo LSTM incluyen: el valor máximo de Tensión equivalente en tiempo real de la Viga Principal inferido por el POD, el número de ciclos de tensión (extraídos mediante el conteo rainflow), la distribución de la media y la amplitud del espectro de carga, el tiempo de funcionamiento acumulado del equipo y la Temperatura Ambiente. La salida es: la vida residual a fatiga de las zonas críticas de la Viga Principal (expresada en número de ciclos) y el nivel de alerta temprana (cuatro niveles: verde, amarillo, naranja y rojo). El modelo utiliza una ventana deslizante de entrada de 720 pasos de tiempo (correspondientes a 12 horas de datos históricos) para predecir la acumulación de Fatiga para los próximos 7 días.
Fuente de datos para el entrenamiento del modelo: antes de la puesta en marcha, el equipo de I+D entrenó el modelo LSTM fuera de línea utilizando 12 meses de datos históricos de funcionamiento de 3 Prototipos de ensayo (que incluyen 1,2 millones de muestras válidas). Tras la puesta en marcha, el modelo se actualiza automáticamente de forma incremental cada 24 horas, incorporando los nuevos datos al conjunto de entrenamiento para adaptarse a las tendencias de Envejecimiento del equipo y a los cambios en las condiciones de operación. En la validación operativa real de octubre de 2025 a junio de 2026, el error absoluto medio porcentual (MAPE) de la predicción a 7 días de la acumulación de Fatiga de la Viga Principal fue del 8,3%. La antelación de la predicción es suficiente para que el equipo de mantenimiento programe las reparaciones antes de una parada no programada.
Además, la plataforma integra un módulo de predicción de vibraciones para la Caja de engranajes del mecanismo de elevación y el rodamiento del motor. Mediante la extracción de características en el dominio del tiempo y la frecuencia de la señal de aceleración (FFT + espectro de envolvente), combinada con el modelo LSTM, es posible alertar con 7 a 14 días de antelación sobre fallos en el Aro Interior o el Aro Exterior del Rodamiento. En los 8 equipos desplegados, el modelo ha emitido un total de 47 alertas tempranas, de las cuales 43 fueron confirmadas como fallos reales tras la inspección y parada en sitio. La precisión de la alerta es del 91,5%, con una antelación media de 11,3 días.
Plataforma de datos: adquisición OPC UA/MQTT, base de datos de series temporales y puerta de enlace API
El sistema de control genera datos, el Gemelo Digital los consume; el puente entre ambos es la plataforma de datos. La arquitectura de la plataforma de datos de Kelude sigue un diseño de tres capas: "adquisición perimetral → almacenamiento → servicio de salida", con una lógica de selección tecnológica clara en cada nivel.
Capa de adquisición perimetral: OPC UA como protocolo principal, MQTT como complemento. En el lado del dispositivo, la puerta de enlace perimetral de adquisición de datos "KruEdge", desarrollada por Kelude, se ejecuta en el PC industrial dentro del Armario de Control y se comunica con el runtime de KruControl mediante el Protocolo Modbus RTU (adaptado a OPC UA). La elección de OPC UA se debe a razones claras: soporta nativamente el modelado de datos (no solo transmite datos brutos, sino datos "con semántica", como "Tensión equivalente máxima de la Viga Principal/MPa/punto de medición FBG-03"), seguridad mediante cifrado (autenticación mutua con certificados X.509 + cifrado de transmisión AES-256) y un mecanismo de reenvío automático de datos históricos. Los datos adquiridos por la puerta de enlace incluyen tres categorías principales: variables de estado del equipo (velocidad, Corriente, Par y posición de los tres mecanismos: Elevación / Izado, traslación del puente y del carro), variables de seguridad (estado del sensor de sobrecarga, Final de Carrera y Freno) y variables de salud estructural (deformación FBG, aceleración y temperatura). En total, suman aproximadamente 600 puntos de datos, con una frecuencia de adquisición configurable de 1 a 100 Hz.
Para los equipos más antiguos que no soportan OPC UA (como los modelos anteriores a 3 años, algunos de los cuales utilizan el Protocolo Modbus RTU), la puerta de enlace perimetral realiza un puente mediante un módulo adaptador de protocolo Modbus a OPC UA. Además, para una pequeña cantidad de datos telemétricos que no requieren alta frecuencia en tiempo real (como posición GPS, Temperatura Ambiente y humedad, estadísticas de consumo energético), se utiliza el protocolo MQTT para informar en ciclos de 5 minutos, reduciendo la carga de datos en la capa de control.
Capa de almacenamiento: arquitectura de almacenamiento híbrido basada en base de datos de series temporales. Con 600 puntos de datos adquiridos continuamente a una frecuencia de 1-100 Hz, una sola pieza de equipo genera aproximadamente 1,5 a 5 GB de datos al día (dependiendo de la densidad de adquisición). Si el 50% de los equipos en venta de Kelude (alrededor de 200 unidades) se conectan a la plataforma de datos, el volumen de escritura anual alcanzaría los 100-360 TB. Una base de datos relacional tradicional no puede soportar tal carga de escritura.
La solución de almacenamiento de Kelude es una arquitectura híbrida de dos niveles: el primer nivel es una caché local: cada puerta de enlace perimetral del equipo está equipada con un SSD NVMe de 256 GB que almacena en caché todos los datos de los últimos 30 días (aproximadamente 45-150 GB por equipo). En caso de interrupción de la red, los datos no se pierden y se reenvían automáticamente cuando se restablece la conexión. El segundo nivel es la base de datos de series temporales en la nube: se utiliza la extensión de código abierto TimescaleDB (basada en PostgreSQL) desplegada en un servidor privado. La estructura de la tabla sigue un patrón de tabla ancha de "ID de equipo + marca de tiempo + ID de punto de medición", con una granularidad de partición temporal de 72 horas. Rendimiento de escritura medido: un solo nodo (8 núcleos, 32 GB) puede manejar de forma estable 240.000 escrituras por segundo, con una latencia de consulta del percentil 95 inferior a 50 ms (para consultas de todos los datos de un solo equipo en un rango de 30 días).
Para abordar el coste de almacenamiento de los datos históricos, el equipo también ha diseñado una estrategia de compresión y agregación de datos: los datos brutos se conservan durante 90 días (para el análisis de fallos y el entrenamiento del modelo); los datos de 90 días a 1 año se reducen a una muestra por minuto (método de agregación: promedio + máximo + mínimo); los datos de más de 1 año se reducen a una muestra por hora. El almacenamiento total de los datos completos más las dos copias de datos reducidos es solo del 12% al 15% del tamaño de los datos brutos originales.
Capa de servicio: puerta de enlace API unificada. Una vez almacenados los datos, ¿quién los consume? El front-end del Gemelo Digital necesita datos de estado en tiempo real, la interfaz web necesita curvas de tendencia históricas, la aplicación para terminal móvil necesita notificaciones de alerta, y los sistemas de terceros (como el MES o ERP del cliente) necesitan interfaces para la integración. Cada consumidor tiene diferentes requisitos de formato de datos, protocolo de transmisión y permisos. Kelude ha desarrollado su propia puerta de enlace API, "KruGateway", para resolver este problema.
KruGateway se ha desarrollado a partir del gateway de código abierto Kong, incorporando funcionalidades personalizadas para entornos industriales: admite el acceso unificado a cuatro protocolos —OPC UA, MQTT, HTTP REST y gRPC—, y todos los datos se convierten internamente al formato JSON estándar antes de distribuirse a los consumidores. La gestión de permisos a nivel de gateway se controla mediante un sistema de tres ejes: «dimensión de dispositivo + dimensión de datos + dimensión de función». Por ejemplo, un cliente puede ver únicamente los 10 dispositivos asignados a su cuenta (dimensión de dispositivo), solo puede consultar datos de estado sin poder modificar los parámetros de control (dimensión de función), y dentro de los datos de estado no puede acceder a los datos de los sensores de seguridad (dimensión de datos). El gateway también incorpora control de flujo de datos y aceleración de caché: para las solicitudes de alta frecuencia del front-end del Gemelo Digital (refresco a 20 fps), el gateway almacena automáticamente en caché las instantáneas de los últimos 3 segundos, evitando así que cada renderización del front-end tenga que consultar la base de datos.
A junio de 2026, KruGateway procesa un promedio de aproximadamente 2,8 millones de llamadas API diarias, con un tiempo de respuesta del percentil 95 inferior a 15 ms y una disponibilidad mensual media del 99,97 %.
Comparativa integral frente a soluciones genéricas: coste, rendimiento y escalabilidad
Los tres enfoques técnicos descritos anteriormente desglosan la lógica subyacente de la solución propia de Kelude. Sin embargo, la decisión final sobre la selección de la tecnología no recae en el equipo de I+D, sino en la dirección, cuya pregunta principal es: ¿en qué aspectos supera realmente esta solución propia a las soluciones genéricas? ¿Merece la pena la inversión adicional en personal y recursos?
La siguiente tabla ofrece una comparativa cuantitativa global desde tres dimensiones: coste, rendimiento y escalabilidad.
| Dimensión de Comparación | Solución propietaria Krud | Solución estándar del sector | DiferenciaAlcance |
|---|---|---|---|
| Costo integral de hardware(Por unidad) | 1.8~2.510,000 CNY | 2.5~410,000 CNY | Bajo20%~40% |
| Tarifa de licencia de software(10Por unidad) | ≈0 | 3~810,000 CNY | Costo de licencia casi nulo |
| Potencia de cómputo de control | ~1210,000DMIPS(i7-12700TE) | ~0.4~1.510,000DMIPS | Alto8~30veces |
| Período de controlPrecisión | 5μsJitter de nivel(PREEMPT_RTTiempo real estricto) | ±1~5msJitter de nivel | PrecisiónAlto100~1000veces |
| AntibalanceoRendimiento(Residualángulo de oscilación) | <0.3°(Plena carga,Totalcondiciones de operaciónAutoadaptativo) | 0.5°~1.5°(RequiereManualAjuste de parámetros,condiciones de operaciónSensible) | Mejora40%~80% |
| Gemelo DigitalTiempo real | 20fpsTotalTensiónSimulación de campo,latencia<100ms | Ninguno(El sector carece generalmente de capacidad de gemelo digital en tiempo real) | De cero a uno |
| mantenimiento predictivoEl sector carece generalmente de capacidad de gemelo digital en tiempo real | LSTMModelo,Rodamientoalerta tempranaCon antelación7~14días,Precisión91.5% | Alarma por umbral(Superación de un valor único) | Salto cualitativo |
| Escalabilidad del sistema | DockerDespliegue contenerizado,OTADiferencialActualización,Soporte para integración de algoritmos propietarios | La expansión de funciones depende del fabricanteactualización de firmware,Imposibilidad de integrar algoritmos propios | Totalmente abierto vs. Ecosistema cerrado |
| Capacidad de integración de datos | OPC UA+MQTT+ModbusTotalmente compatible,Soporte para sistemas de tercerosRESTIntegración | Requiere además un gateway industrial oSistema SCADA | Integrado vs. Solución fragmentada |
De la comparación anterior se desprende una línea lógica clara: el «techo» de la solución PLC genérica no es un problema de precio, sino de arquitectura. Su capacidad de cómputo, tiempo real, apertura y escalabilidad determinan que solo pueda permanecer en el nivel de «control lógico programable», sin poder albergar capacidades de orden superior como algoritmos inteligentes, Gemelo Digital y análisis de macrodatos industriales. La solución IPC + Linux en tiempo real de Kelude consiste, en esencia, en «degradar» una computadora industrial de alto rendimiento al rol de Controlador: se intercambia el excedente de capacidad de cómputo por flexibilidad de desarrollo y margen de expansión futura.
Por supuesto, esta solución también tiene su coste. El mayor es la inversión en I+D: desde el inicio del proyecto en 2021 hasta el despliegue en producción en 2024, la plataforma KruControl acumuló una inversión de desarrollo superior a 32 millones de CNY (aprox. 4,1 millones EUR), con más de 120 personas-año dedicadas. Para una empresa manufacturera de tamaño medio con una facturación de varios cientos de millones de CNY, es una cifra bastante «visible» en los estados financieros. El segundo coste es la gestión de la cadena de suministro: la compra de componentes para el PC industrial, el ciclo de fabricación de las placas base personalizadas (una media de 12 a 16 semanas) y la adaptación y validación del kernel Linux en tiempo real son mucho más complejos que comprar un PLC estándar.
No obstante, la dirección de Kelude tiene clara su apuesta por esta línea tecnológica: en el punto de inflexión en el que el sector de la grúa pasa de la «competencia por volumen» a la «competencia por tecnología», el «suficiente» del PLC genérico se está convirtiendo en «insuficiente». En lugar de esperar a que los competidores acaparen primero el mercado de gama alta con soluciones propias, es preferible invertir tres años en cavar bien el foso tecnológico.
Conclusión
Volviendo al título de este artículo: más allá de fabricar grúas. Kelude Industrias Pesadas lleva veinte años construyendo grúas, pero lo que realmente la diferencia de sus competidores no es la capacidad de fabricar mayores tonelajes ni de asumir los pedidos más complejos, sino lo que ocurre en las «partes invisibles» de la grúa: cada línea de código del sistema de control, cada función base del Gemelo Digital y cada tubería de datos de la plataforma de datos central están desarrolladas internamente.
La solución PLC genérica es sin duda madura y fiable, pero el límite que define es, precisamente, el techo de rendimiento de la grúa. Kelude opta por romper ese techo con IPC + Linux en tiempo real, convierte el Gemelo Digital de herramienta de demostración en herramienta de ingeniería mediante el modelo reducido POD, y transforma los datos del equipo en activos empresariales con su plataforma de datos central propia. Estos tres pilares conforman la base tecnológica de Kelude Industrias Pesadas en el ámbito de la Grúa Inteligente.
Este camino no ha sido rápido —desde el inicio en 2021 hasta la producción en serie en 2024, han pasado más de tres años—; tampoco ha sido barato: 32 millones de CNY (aprox. 4,1 millones EUR) de inversión en I+D no es una cifra menor para una empresa manufacturera. Pero en el equipo de Kelude existe un consenso: el foso tecnológico es el único activo que la guerra de precios no puede erosionar. Lo que la solución PLC genérica no puede hacer, la solución propia de Kelude sí puede. Ahí reside el origen de la diferenciación.
Preguntas frecuentes
P: ¿Cuál es la diferencia esencial entre el sistema de control propio IPC + Linux en tiempo real de Kelude y un PLC genérico?
R: La diferencia esencial radica en la apertura de la arquitectura del sistema y en el techo de capacidad de cómputo. En el PLC genérico, el software y el hardware están cerrados y definidos por el fabricante; el usuario solo puede programar dentro del marco establecido por el fabricante (p. ej., diagrama de escalera, lenguaje SCL), sin posibilidad de ejecutar algoritmos propios de alto nivel, y la capacidad de cómputo está limitada por procesadores ARM de bajo consumo. La solución IPC de Kelude utiliza procesadores Intel x86, con una capacidad de cómputo de 8 a 10 veces superior a la de un PLC de gama alta, incorpora el kernel Linux en tiempo real PREEMPT_RT y permite ejecutar código arbitrario en C++/Python en espacio de usuario, con soporte para despliegue en contenedores y Actualización remota OTA. En resumen, el PLC es un «controlador lógico programable», mientras que la solución IPC es una «computadora industrial programable»: el primero logra el control; el segundo, la integración de control + cómputo + expansión.
P: ¿Qué es el modelo reducido POD y por qué es tan importante para el Gemelo Digital?
R: POD (Proper Orthogonal Decomposition, descomposición ortogonal propia) es un método de reducción de orden de modelos basado en datos. Mediante la descomposición en valores singulares de un gran volumen de datos precalculados, extrae los «modos base» de mayor contribución energética y comprime la resolución FEA de alta dimensión, que antes requería minutos, a un cálculo de interpolación de baja dimensión de decenas de milisegundos. Para el Gemelo Digital, sin la reducción POD, la inferencia del campo de Tensión en tiempo real sería una tarea imposible —no se puede pedir al operador que espere de 3 a 5 minutos a que el FEA termine para ver el resultado. La solución de Kelude reconstruye el 99,2 % de la información de 1000 grupos de condiciones de operación con 15 modos base, con un tiempo de cálculo en línea de solo 15 a 30 ms.
P: ¿Cómo gestiona la plataforma de datos central de Kelude los volúmenes masivos de datos de los equipos?
R: Se adopta una arquitectura de tres niveles. Nivel de borde (puerta de enlace KruEdge): cada equipo almacena localmente 30 días de datos completos (aprox. 45 a 150 GB); si la red se interrumpe, se almacenan automáticamente en caché y se retransmiten al restablecerse. Nivel de almacenamiento: basado en la base de datos de series temporales TimescaleDB, un solo nodo procesa 240 000 escrituras por segundo; los datos brutos se conservan durante 90 días y luego se reducen automáticamente la frecuencia de muestreo a nivel de minutos y horas. Nivel de servicio: la puerta de enlace API KruGateway proporciona salida unificada hacia el exterior, con soporte para cuatro protocolos: OPC UA, MQTT, HTTP REST y gRPC; gestiona una media de 2,8 millones de llamadas API al día, con un percentil 95 de respuesta inferior a 15 ms. La gestión de permisos se controla en tres dimensiones —«equipo + datos + funcionalidad»— para garantizar la seguridad de los datos en escenarios multiinquilino.
P: ¿Esta solución propia es adecuada para todos los clientes?
R: Por el momento se dirige principalmente a clientes y escenarios de aplicación con altos requisitos de inteligencia, como los sectores de metalurgia, Puerto y energía nuclear, que necesitan operación remota, gestión de la salud de los equipos o mantenimiento optimizado. Para escenarios genéricos que solo requieren funciones básicas de Izaje, Kelude sigue ofreciendo una línea de productos estándar basada en soluciones PLC maduras. La solución propia y la solución genérica coexisten en paralelo: la primera busca la diferenciación y construye barreras tecnológicas; la segunda cubre el mercado base sensible al precio. Ambas vías no son excluyentes, sino que responden a una estrategia de productos por capas dirigida a distintos segmentos de clientes.