Guía de selección de plataforma de datos para grúas
Recomendación de stack tecnológico para plataforma de datos de puentes grúa: InfluxDB para series temporales (almacenamiento permanente de datos de características) o TDengine para escalas masivas; Kafka+Flink para procesamiento de flujo (alertas en tiempo real + cálculo de características); Grafana para visualización (paneles en tiempo real + notificaciones de alertas).La plataforma de datos de Kelude Industrias Pesadas utiliza por defecto el stack InfluxDB+Kafka+Flink+Grafana, con un coste de hardware de aproximadamente 8.000–15.000 € por estación (20 puentes grúa) y un coste anual de mantenimiento de unos 3.000–5.000 €.
Al construir una plataforma de datos para puentes grúa, la elección del stack tecnológico determina directamente el rendimiento, el coste y la mantenibilidad del sistema. En el mercado existen decenas de opciones para bases de datos de series temporales, motores de procesamiento de flujo y herramientas de visualización. Este artículo se basa en la experiencia real de Kelude Industrias Pesadas en más de 200 puentes grúa, parte de las necesidades específicas del entorno industrial de estos equipos, compara las principales soluciones técnicas y ofrece una combinación recomendada.
Base de datos de series temporales: InfluxDB vs TimescaleDB vs TDengine
El almacenamiento principal de la plataforma de datos de puentes grúa es la base de datos de series temporales, responsable de almacenar datos de características a nivel de segundo (128 dimensiones × 1 Hz), datos de eventos a nivel de milisegundo y metadatos de equipos. Comparativa detallada de las tres opciones principales:
| Elemento de comparación | Influx DB 2.x | Timescale DB | TDengine 3.x |
|---|---|---|---|
| Rendimiento de escritura(Nodo único) | ~3Diez mil puntos/Segundos | ~2Diez mil puntos/Segundos | ~500Diez mil puntos/Segundos |
| Relación de compresión | 5:1 | 12:1 | 10:1 |
| Latencia de consulta(1hAlcance) | ≤200ms | ≤500ms | ≤300ms |
| Lenguaje de consulta | Flux(Curva de aprendizaje pronunciada) | Norma SQL | Norma SQL+Escalabilidad |
| Complejidad de despliegue | Sencillo(Docker Un clic) | Medio(Requiere Postgre SQL) | Sencillo(Sencillobin Archivo) |
| Licencia de código abierto | MIT(Edición comunitaria) | TSL(Edición comunitaria) | AGPL(Edición comunitaria) |
| Ámbito de aplicación | 20~100Unidadespuente grúa | Requiere vincular tablas de negocio | 100~500Unidadespuente grúa |
Recomendación de Kelude: Para plantas medianas con 20~100 puentes grúa, elija InfluxDB: es el que ofrece mejor rendimiento de consultas, la comunidad más activa y la integración más madura con Grafana. Para plantas grandes con más de 100 unidades, elija TDengine: su rendimiento de escritura es muy superior. Si necesita asociar los datos del puente grúa con la planificación de producción o el registro de equipos, elija TimescaleDB.
2. Motor de procesamiento de flujo: comparativa Kafka vs. Flink vs. Node-RED
Los datos de características que envía la pasarela perimetral deben pasar por un motor de procesamiento de flujo para realizar la detección de alarmas, el cálculo de agregaciones y el enrutamiento de datos. Cada una de las tres opciones tiene un enfoque distinto:
| Elemento de comparación | Kafka+Connectors | Flink | Node-RED |
|---|---|---|---|
| Capacidad de rendimiento | Millonesmsg/s | 50Millonesevent/s | 1Milmsg/s |
| Latencia de procesamiento | 5~10ms | <1ms | 10~50ms |
| Gestión de estado | Sin estado | Con estado(exactly-once) | Limitado(context Variables) |
| Agregación por ventanas | Kafka Streams Soporta | Integrado(tumble/slide/session) | Requiere implementación propia |
| Complejidad operativa | Alta(Zoo Keeper/KRaft) | Alta(Job Manager Clúster) | Baja(Proceso único) |
| Adaptación de protocolo | REST/RPC | Kafka Conexión | MQTT/OPCUA/Modbus/HTTP |
Recomendación de Kelude: Para la solución estándar, se recomienda Kafka (capa de buffer de datos) + Flink (motor de alertas en tiempo real y cálculo de características). Node-RED se utiliza como convertidor de protocolo ligero en el edge (MQTTKafka). Con la integración de los tres componentes, la latencia de alertas de Flink en el edge para una estación individual (20 puentes grúa) es ≤500 ms.
3. Panel de visualización: Grafana vs Superset
El panel es la interfaz final donde los datos del puente grúa se presentan al personal. Ambas soluciones de código abierto tienen sus ventajas:
Grafana (recomendado): La opción preferida para el monitoreo en tiempo real de puentes grúa. Compatibilidad nativa con InfluxDB/TDengine como fuentes de datos, plantillas integradas de gráficos de series temporales (gráficos de líneas temporales, mapas de calor, paneles de estado), gestión de reglas de alerta y notificaciones multicanal (WeChat, DingTalk, correo electrónico). El motor de alertas de Grafana se basa en Prometheus AlertManager y se puede integrar con el mini programa de WeChat de Kelude Industrias Pesadas mediante Webhook. Ejemplo de configuración: panel de tendencia RMS de vibración de rodamientos (refresco cada 10 segundos, alerta cuando supera 2 veces la línea base). Un solo nodo de Grafana puede atender a más de 100 usuarios concurrentes.
Superset: Adecuado para escenarios de informes de gestión: informes mensuales de eficiencia energética, gráficos de tendencia OEE, estadísticas de costes de mantenimiento. La consulta SQL mediante arrastrar y soltar de Superset es más amigable para usuarios no técnicos, pero su capacidad de refresco en tiempo real es limitada (intervalo mínimo de refresco: 60 segundos). La plataforma de big data de Kelude Industrias Pesadas integra tanto Grafana (paneles en tiempo real) como Superset (informes de gestión), permitiendo al usuario alternar entre ambos desde la misma página.
¥8~15Millones Costo de hardware por estación(20Unidades) Incluye caja de borde+servidor+Equipos de red | 3~5Millones/Años Costo operativo anual Incluye almacenamiento de datos+Mantenimiento de modelos+Panel de control | 100% Código abierto Componente Tasa de uso Sin riesgo de bloqueo por software comercial |
500ms Latencia de alertas Borde Flink Notificación de alertas de extremo a extremo | 28Paneles Número de la norma de paneles Visión general operativa/Dispositivo individual/Tres tipos de análisis histórico | 14Días Período de prueba gratuito Integración2Unidadespuente grúa Experiencia completa |
4. Configuración de hardware y arquitectura de despliegue
La configuración de hardware de la plataforma de datos masivos estándar de Kelude (para una flota de 20 puentes grúa) es la siguiente: en el lado del edge, cada puente grúa incorpora un Jetson Orin NX (≈3.500–7.000 CNY/unidad, incluido el kit de sensores); en el lado del servidor, se incluye un servidor estándar (Dell R750xs o equivalente, ≈40.000–60.000 CNY) con InfluxDB + Kafka + Flink + Grafana + PostgreSQL + MinIO. La configuración recomendada es: doble Intel Xeon Silver 4314 (32 núcleos / 64 hilos), 128 GB de RAM, 4×8 TB SSD (RAID10) y tarjeta de red dual de 25 GbE. Con una tasa de utilización del puente grúa del 80 % y un incremento diario de datos de características de 1,2 GB por unidad, se pueden conservar 90 días de datos activos más almacenamiento en frío permanente.
Kelude ofrece un plan de despliegue completo de la pila tecnológica. Para más aplicaciones de datos, consulte la interpretación completa del flujo de datos del puente grúa y la comparativa de precisión de los modelos de mantenimiento predictivo. Para consultas sobre la selección de la pila tecnológica, contacte con el equipo de datos masivos de Kelude para obtener una solución personalizada.
Preguntas frecuentes sobre la plataforma de datos del puente grúa
P: ¿Cuánto tiempo se tarda en desplegar la plataforma de datos masivos?
R: El ciclo de despliegue estándar de Kelude es el siguiente: instalación de sensores (3–5 días por unidad, con posibilidad de trabajo en paralelo), puesta en marcha del edge box (2 días por estación), montaje del servidor e implementación de Kafka/Flink/InfluxDB (3 días), configuración de los paneles de Grafana (2 días) y entrenamiento inicial del modelo (comienza tras 7 días de acumulación de datos). Desde la llegada del equipo hasta la puesta en marcha de los paneles se necesitan aproximadamente 15–20 días laborables. La reforma de puentes grúa existentes no requiere detener la producción.
P: ¿Cómo se garantizan la seguridad de los datos y la privacidad?
R: La plataforma de datos masivos de Kelude admite un despliegue totalmente privado: los datos nunca salen de la planta. La comunicación con el servidor perimetral utiliza cifrado TLS 1.3 con autenticación mutua mediante certificados. La capa de almacenamiento admite cifrado transparente (AES-256). Los permisos de usuario se controlan mediante RBAC y los registros de operaciones son totalmente trazables. También se admite un canal de telemantenimiento por VPN, y el personal de mantenimiento de Kelude no accede directamente a ningún dato. La plataforma cuenta con la certificación ISO 27001 y cumple los requisitos de seguridad y cumplimiento normativo de los sectores siderúrgico y químico.
P: Hemos elegido InfluxDB como base de datos. ¿Cómo abordamos la ampliación futura?
R: InfluxDB 2.x admite una arquitectura multiinquilino con aislamiento por organización. Las opciones de ampliación son: vertical (aumentar la RAM y la CPU del servidor) u horizontal (la versión Enterprise de InfluxDB admite clústeres). La edición estándar de Kelude recomienda comenzar con una ampliación vertical de un solo nodo (64 GB de RAM pueden soportar 500.000 series/segundo de lectura); cuando el número de series supere los 2 millones, se migra a un clúster TDengine. Kelude proporciona la herramienta de migración de datos, y el proceso es transparente para los paneles de Grafana.
P: La red de la fábrica es deficiente. ¿Qué ocurre si no podemos usar Kafka?
R: Kelude ofrece un plan de despliegue "offline-first": el edge box incorpora una cola de mensajes integrada (NATS) que almacena datos en caché durante las interrupciones de red (hasta 72 horas de datos, aproximadamente 3,6 TB por unidad) y los sincroniza automáticamente por lotes cuando se restablece la conexión. El edge box también puede ejecutar la lógica de alertas de forma local e independiente, sin depender de la nube. Esta solución ya se ha aplicado en un proyecto de recopilación de datos de puentes grúa en una zona minera del oeste de China, donde las interrupciones de red acumuladas alcanzaron unas 48 horas al mes, sin pérdida de datos.
La selección de la pila tecnológica para una plataforma de datos masivos de puentes grúa debe tener en cuenta el tamaño de la planta, la capacidad del equipo de TI, el presupuesto y los planes de expansión. Kelude ofrece dos modalidades: edición estándar (20–100 unidades) y edición empresarial (sin límite de unidades), ambas con pila tecnológica de código abierto y sin costes de licencia comercial. Contacte con el equipo técnico de Kelude para obtener una prueba gratuita y una propuesta de selección.
