Mantenimiento predictivo con aprendizaje federado para puentes grúa
Solución de mantenimiento predictivo para puentes grúa con aprendizaje federado
Los datos de vibración de los puentes grúa de tres empresas siderúrgicas (plantas A/B/C, con 50 puentes grúa cada una) no pueden centralizarse en un único servidor para su entrenamiento debido a requisitos de cumplimiento normativo y confidencialidad de los procesos. El enfoque de aprendizaje federado: cada planta entrena un modelo predictivo LSTM en su servidor GPU local, y en cada ronda solo se cargan 512 KB de pesos del modelo al servidor central, que ejecuta la agregación FedAvg y distribuye las actualizaciones. Tras 100 rondas de comunicación, el modelo converge con un F1 global de 0,91, muy cercano al F1=0,93 del entrenamiento centralizado (diferencia de solo el 2%). En cambio, el entrenamiento independiente de una sola planta sin aprendizaje federado (datos de 50 unidades) alcanza un F1=0,85. El aprendizaje federado, preservando la privacidad de los datos, eleva el F1 de 0,85 a 0,91.
Los modelos de mantenimiento predictivo de puentes grúa dependen de grandes volúmenes de datos de entrenamiento que cubran diversas condiciones de operación y modos de fallo. Sin embargo, en la práctica, un usuario individual de puentes grúa (una fábrica) suele disponer de entre 20 y 80 unidades, una cantidad insuficiente para entrenar un modelo LSTM de predicción de vida útil restante (RUL) de alta precisión (F1≈0,85 en una sola planta). Aunque consolidar los datos de varias plantas para un entrenamiento conjunto mejoraría la precisión (F1=0,93), esta opción plantea riesgos de cumplimiento por la salida de datos de las instalaciones (Ley de Seguridad de Datos, Ley de Protección de Información Personal) y las exigencias de confidencialidad de los procesos productivos. El aprendizaje federado (Federated Learning, FL) permite el entrenamiento colaborativo entre múltiples plantas mediante el principio de ”los datos no se mueven, el modelo sí”. Entorno experimental: PyTorch 2.1.0 + framework Flower 1.7.0, 3 clientes con 1×RTX 4090 cada uno y 1 servidor central con CPU.
Proceso de aprendizaje federado en puentes grúa
Se emplea el algoritmo FedAvg (promedio federado): en la ronda t, ① el servidor central distribuye el modelo global W_t a los 3 clientes; ② cada cliente entrena con sus datos locales durante E=5 épocas (Batch=64, lr=0.001, optimizador SGD) y obtiene la actualización ΔW_i; ③ el cliente carga ΔW_i (solo el incremento de pesos, 512 KB/vez) al servidor central; ④ el servidor ejecuta W_{t+1}=W_t+∑(n_i/N)·ΔW_i (donde n_i es el volumen de datos del cliente i y N el volumen total); ⑤ se repite durante T=100 rondas. El tiempo de comunicación por ronda es de aproximadamente 2 segundos (incluyendo transmisión de red y entrenamiento local), y las 100 rondas completas tardan unos 8 minutos.
Comparativa de precisión del modelo
| esquema | escala de datos | F1puntuación | MAPE | si los datos salen de fábrica | volumen de transmisión |
|---|---|---|---|---|---|
| independiente por fábrica(Asi los datos salen de fábrica) | 50unidad×24mes | 0.85 | 18.2% | no | 0 |
| centralizado(consolidación de tres plantas) | 150unidad×24mes | 0.93 | 14.3% | sí(todos los datos) | TBnivel |
| aprendizaje federado(tres plantas FL) | 150unidad×24mes | 0.91 | 15.1% | no(solo pesos) | ~50MB |
| aprendizaje federado(no IID+aumentado) | 150unidad×24mes | 0.92 | 14.8% | no(solo pesos) | ~50MB |
El aprendizaje federado alcanza un F1=0.91 frente al 0.93 del enfoque centralizado, una diferencia de solo el 2%. Tras aplicar una estrategia de optimización para datos non-IID (cuando la distribución de datos varía entre fábricas, se añade un término proximal a la función de pérdida local, según el algoritmo FedProx), el F1 mejora hasta 0.92. El entrenamiento aislado de una sola fábrica obtiene un F1=0.85; el aprendizaje federado incrementa el F1 en 0.06 (6 puntos porcentuales), logrando una precisión cercana a la del enfoque centralizado sin comprometer la privacidad de los datos.
Desafíos de datos non-IID y su solución
El principal desafío del aprendizaje federado reside en los datos non-IID (no independientes e idénticamente distribuidos): la distribución de modelos de puente grúa, condiciones de operación y modos de fallo difiere entre fábricas (la fábrica A presenta principalmente degradación de rodamientos en el taller de laminación en caliente; la fábrica B, picadura de engranajes en el taller de laminación en frío; la fábrica C, fallos por alta temperatura en el taller de fundición). El algoritmo estándar FedAvg converge lentamente en escenarios non-IID (requiere 150 rondas frente a las 80 rondas en entornos IID), y el F1 del modelo global desciende de 0.91 a 0.87. Solución: ① Ajuste local: tras la distribución del modelo global, se realiza un entrenamiento adicional de 5 épocas en el cliente para adaptarse a la desviación de la distribución; ② Aumento de datos: los clientes comparten las características estadísticas de la distribución (sin compartir los datos) para alinear el espacio de características. Con estas medidas, el F1 en escenarios non-IID se recupera hasta 0.90.
Optimización de la eficiencia de comunicación
El coste de comunicación del aprendizaje federado constituye el principal cuello de botella en su despliegue real. El volumen de transmisión se reduce del orden de TB del enfoque centralizado a 50MB en FL (100 rondas × 512KB), pero en entornos industriales con ancho de banda limitado (red 4G pública con aproximadamente 10Mbps de subida) sigue siendo necesario optimizarlo. Comparativa de cuatro estrategias de optimización:
| estrategia de optimización | volumen de comunicación/ronda | F1puntuación | F1pérdida | Ámbito de aplicación |
|---|---|---|---|---|
| Baseline(FP32gradiente completo) | 512KB | 0.910 | referencia | buenas condiciones de red(red industrial privada) |
| Top-kesparsificación(k=10%) | 51KB | 0.907 | -0.003 | ancho de banda limitado(4G/5Gred pública) |
| INT8cuantización | 128KB | 0.909 | -0.001 | ancho de banda limitado pero aceptable FP16 |
| local Epoch=10(60ronda) | 512KB | 0.902 | -0.008 | alta latencia de red(interprovincial) |
| Fed Async Asíncronoagregación | 512KB | 0.884 | -0.026 | heterogeneidad de clientes(desconexiones frecuentes) |
Combinación recomendada: cuantización INT8 (128 KB/ronda, pérdida de F1 del 0,1 %) + entrenamiento local con Epoch=10 (60 rondas, pérdida de F1 del 0,8 %). El tráfico de comunicación se reduce al 25 % del valor de referencia, con un F1 total de 0,90.
Protección de la privacidad diferencial
Aunque solo se transmitan los gradientes del modelo y no los datos originales, persiste el riesgo de ataques de fuga de gradientes (Deep Leakage from Gradients, Zhu et al., 2019). La privacidad diferencial (DP) se defiende añadiendo ruido gaussiano a los gradientes: perturbed_grad = clip(grad, C) + N(0, sigma^2 * C^2 * I). En este experimento se establece un clip de gradiente C=1,0, una desviación estándar de ruido sigma=0,01, lo que corresponde a un presupuesto de privacidad epsilon=8 (según GB/T 35273-2020, epsilon≤10 se considera un nivel aceptable). DP-SGD reduce el F1 de 0,91 a 0,89 (una caída del 2 %), a cambio de una garantía de privacidad demostrable.
Validación en despliegue real
Proyecto de aprendizaje federado para el mantenimiento predictivo de puentes grúa en tres filiales de un grupo siderúrgico (plantas A/B/C, código KL-FL-2024-001, de marzo de 2025 a marzo de 2026). Cada planta cuenta con 50 puentes grúa equipados con sensores PCB 352C33, pasarelas KL-EDGE-200 y modelos LSTM. Tras la puesta en marcha del aprendizaje federado: el F1 de predicción de RUL en la planta A pasó de 0,83 a 0,90 (+7 pp); en la planta B, de 0,87 a 0,91 (+4 pp); y en la planta C (con escasos fallos por alta temperatura en fundición), de 0,79 a 0,88 (+9 pp). La planta C mostró la mejora más notable, ya que los datos de degradación de rodamientos y engranajes de las plantas A y B complementaron los modos de fallo por alta temperatura. Con entrenamiento centralizado (suponiendo que los datos pudieran consolidarse), el F1 sería de 0,93; el aprendizaje federado logra una diferencia de solo 2 puntos de precisión a cambio de garantizar que los datos no salgan de las instalaciones, cumpliendo así con los requisitos normativos.
Comparativa completa: aprendizaje federado vs. centralizado vs. planta individual
| Dimensión de Comparación | independiente por fábrica | entrenamiento centralizado | aprendizaje federado Fed Avg | federado+DP(epsilon=8) |
|---|---|---|---|---|
| F1puntuación | 0.85 | 0.93 | 0.91 | 0.89 |
| si los datos salen de fábrica | no | sí(TBnivel) | no(solo pesos) | no(pesos con ruido) |
| riesgo de cumplimiento | ninguno | alta latencia de red(ley de seguridad de datos) | bajo | mínimo(demostrable) |
| volumen de transmisión | 0 | TBnivel | 50MB | 50MB |
| tiempo total de entrenamiento | 15min | 45min | ~8min(comunicación) | ~9min |
| requisitos de hardware | planta única GPU | centro GPUclúster | suministrado por cada planta GPU | suministrado por cada planta GPU |
| Ámbito de aplicación | planta única con datos suficientes | datos centralizables | datos no exportables de fábrica | altos requisitos de cumplimiento |
Preguntas frecuentes
P: Con pocos datos locales (solo 10 puentes grúa), ¿merece la pena participar en el aprendizaje federado?
R: Sí. Aunque el volumen de datos de una sola planta sea reducido (10 equipos), participar en el aprendizaje federado sigue aportando beneficios. El modelo global aprende patrones de degradación generales a partir de los datos de múltiples plantas, y el ajuste local del cliente con pocos datos adapta el modelo general a equipos específicos. En las pruebas ampliadas de este estudio: una planta con 10 equipos (F1=0.72) que se incorpora al aprendizaje federado alcanza F1=0.87, una mejora de 15 puntos porcentuales.
P: ¿Cómo se garantiza la seguridad de las comunicaciones en el aprendizaje federado?
R: Se recomiendan las siguientes medidas de seguridad: ① Cifrado de gradientes — uso de privacidad diferencial (DP-SGD, ε=8), añadiendo ruido gaussiano (σ=0.01) antes de la subida de pesos para prevenir ataques de fuga de gradientes; ② Cifrado de comunicaciones — cifrado de transporte TLS 1.3 para evitar escuchas de intermediarios; ③ Autenticación de clientes — autenticación mutua mediante certificados x.509, permitiendo solo la participación de clientes autorizados en la agregación.
P: ¿Qué ocurre si la red de una fábrica es inestable y se interrumpe la conexión?
R: El framework Flower admite agregación asíncrona (FedAsync) y mecanismos de tolerancia a fallos: el servidor central espera un tiempo de espera máximo (60 segundos por defecto); si se supera, omite ese cliente y continúa la agregación con las actualizaciones de los demás. El cliente desconectado puede solicitar el modelo global más reciente al volver a conectarse. En este estudio se simuló la desconexión aleatoria de un solo cliente (probabilidad del 10%), y el F1 final pasó de 0.91 a 0.88 (pérdida del 3%), manteniéndose por encima del 0.85 de una planta independiente.
P: ¿Es necesario que todas las fábricas dispongan de la misma plataforma de hardware para desplegar el aprendizaje federado?
R: No. El framework Flower admite clientes heterogéneos (Linux/Windows, GPU/CPU, PyTorch/TensorFlow). Cada fábrica entrena con su propio hardware: la fábrica A con RTX 4090 (3 min/iteración), la B con RTX 3060 (5 min/iteración) y la C con CPU (15 min/iteración). El servidor central realiza la agregación síncrona siguiendo la estrategia de "esperar al 30% del cliente más rápido".
