API de mantenimiento predictivo PHM para puente grúa

Los datos operativos acumulados por el sistema de gestión de salud predictiva (PHM) del puente grúa solo pueden transformarse de una herramienta de alertas aislada a un centro de datos integrado en la toma de decisiones de producción cuando se conectan con el sistema de ejecución de fabricación (MES) del taller y las plataformas de gestión superiores. Recientemente, Kelude ha abierto oficialmente la API RESTful de su sistema de mantenimiento predictivo PHM para puentes grúa. Hasta el cierre de esta edición, se ha completado la integración y depuración de datos con 30 fabricantes de MES, cubriendo los tres tipos principales de sistemas: MES metalúrgico, MES de fabricación discreta y WMS de almacenamiento. Con la apertura de la API, los datos de estado en tiempo real, los eventos de alerta y las recomendaciones de mantenimiento del puente grúa pueden enviarse directamente a la plataforma de gestión de producción existente del cliente, sin que el operador necesite cambiar entre múltiples sistemas para consultar. Este artículo presenta sistemáticamente la especificación técnica de la API, el proceso de integración, los escenarios de aplicación típicos y los resultados de la depuración conjunta.

Arquitectura de la API PHM y modelo de datos

La API PHM abierta sigue la especificación OpenAPI 3.0, adopta un estilo arquitectónico RESTful y admite dos formatos de serialización de datos: JSON y Protocol Buffers. La API se divide en cinco categorías de interfaces según el tipo de recurso, cubriendo todas las capacidades de datos centrales del sistema PHM del puente grúa.

API de estado en tiempo real del equipo (Realtime Status API): proporciona una consulta de un solo clic del estado operativo actual del puente grúa. Los endpoints principales incluyen: GET /api/v1/crane/{craneId}/status (devuelve los parámetros operativos actuales: coordenadas X/Y de la posición del puente, altura de elevación, velocidad de traslación, corriente del motor, estado del freno, lecturas del limitador de sobrecarga, etc., con un total de 36 campos y una frecuencia de actualización de 1 segundo), GET /api/v1/crane/{craneId}/health (devuelve la puntuación de salud del equipo, un índice de salud de 0 a 100 calculado mediante la fusión de parámetros multidimensionales, actualizado cada 5 minutos) y GET /api/v1/crane/{craneId}/alerts (devuelve la lista de alertas pendientes actuales, con filtrado por grado de severidad y tipo de alerta).

API de datos históricos (History API): proporciona consultas por lotes de datos operativos del equipo e historial de alertas. Los endpoints incluyen: GET /api/v1/crane/{craneId}/timeseries (consulta datos de series temporales históricas de parámetros específicos en un rango de tiempo, con soporte para exportación continua de hasta 30 días y período de muestreo configurable en tres niveles: 1 segundo, 10 segundos y 1 minuto), GET /api/v1/crane/{craneId}/alerts/history (consulta la lista de eventos de alerta históricos, incluyendo hora de generación, hora de resolución, tipo de alerta, grado de severidad y estado de procesamiento) y GET /api/v1/crane/{craneId}/maintenance (consulta los registros de mantenimiento del equipo, incluyendo tipo de mantenimiento, fecha, contenido y ejecutor). La API de datos históricos se utiliza principalmente para que el sistema MES genere informes de análisis OEE del equipo y la planificación de programas de mantenimiento.

API de notificación de alertas (Alert Webhook API): permite que la plataforma MES se suscriba a los eventos de alerta del sistema PHM mediante Webhooks. El cliente configura las reglas de notificación de alertas en el panel web de PHM (especificando la URL de destino, el umbral de grado de alerta y la frecuencia de envío). Cuando el sistema PHM genera un nuevo evento de alerta, envía automáticamente una solicitud POST a la URL del Webhook configurado, con el cuerpo de la solicitud en formato JSON con los datos del evento. El Webhook admite un mecanismo de reintento: si el primer envío falla, se reintenta después de 30 segundos, con un máximo de 3 reintentos. Si los tres reintentos fallan, se cambia a notificación por correo electrónico al administrador para su procesamiento manual. La latencia mediana de entrega del Webhook es de 5 segundos (desde que PHM detecta la anomalía hasta que el sistema MES del cliente recibe el mensaje).

API de gestión de dispositivos (Device Management API): proporciona operaciones CRUD para la información básica del equipo del puente grúa. Admite el alta de nuevos dispositivos (POST /api/v1/crane, con generación automática del identificador único del dispositivo y los parámetros de configuración iniciales), la actualización de la configuración del dispositivo (PATCH /api/v1/crane/{craneId}, para modificar umbrales de alerta, frecuencia de muestreo, etc.), la consulta de la lista de dispositivos (GET /api/v1/cranes, con filtrado por taller, tipo de equipo y estado operativo) y la eliminación de dispositivos (DELETE /api/v1/crane/{craneId}, que requiere confirmación secundaria). La API de gestión de dispositivos permite que el sistema MES del cliente registre automáticamente el equipo en el sistema PHM al añadir un nuevo puente grúa, sin necesidad de acceder manualmente al panel de PHM.

API de modelos y diagnóstico (Model API): proporciona la gestión de modelos de diagnóstico de IA y la consulta de resultados de diagnóstico. Los endpoints incluyen: GET /api/v1/model/{modelId}/info (consulta la información de un modelo de diagnóstico específico: número de versión del modelo, fecha de implementación, modelos de puente grúa compatibles e indicadores de precisión), POST /api/v1/crane/{craneId}/diagnose (activa un diagnóstico de salud inmediato para un puente grúa específico, devolviendo el estado de salud de cada subsistema y las medidas de mantenimiento recomendadas) y GET /api/v1/crane/{craneId}/diagnose/history (consulta la lista de informes de diagnóstico históricos). La API de modelos permite que el sistema de despacho MES del cliente consulte proactivamente el estado de salud del puente grúa antes de la planificación de la producción, evitando asignar tareas de producción a equipos en mal estado.

Solución técnica de integración y certificación de seguridad

La API PHM utiliza el modo de credenciales de cliente OAuth 2.0 (Client Credentials Grant) para la autenticación de identidad. En la primera integración, el sistema MES del cliente solicita un ID de cliente (client_id) y una clave de cliente (client_secret) a través de la plataforma de desarrolladores de PHM, y luego obtiene un token de acceso (access_token) mediante el endpoint POST /oauth/token. El token tiene una validez predeterminada de 24 horas; una vez caducado, debe renovarse con refresh_token. Los límites de frecuencia de solicitud de la API son: la API de estado en tiempo real admite un máximo de 6000 consultas por hora (aproximadamente 1,67 por segundo de media), la API de datos históricos admite un máximo de 360 consultas por hora, y las API de notificación de alertas y diagnóstico de modelos no tienen límite de frecuencia. El tiempo de respuesta de la interfaz es inferior a 500 ms en el percentil 99 (excluyendo la transmisión de red lenta).

La transmisión de datos utiliza cifrado TLS 1.3. La puerta de enlace de la API está implementada en Alibaba Cloud API Gateway, con soporte para WAF (Web Application Firewall) y protección DDoS. Los registros de solicitudes de la API incluyen la marca de tiempo, el ID del cliente, la ruta de la solicitud, el código de estado de respuesta y el tiempo de respuesta de cada llamada. El período de retención de registros es de 180 días. El cliente puede consultar de forma autónoma las estadísticas de uso de la API (volumen diario de llamadas, tasa de éxito, tiempo de respuesta medio, etc.) a través de la plataforma de desarrolladores. La plataforma ofrece un entorno de pruebas (sandbox) donde el cliente puede desarrollar y depurar la integración con datos simulados antes de cambiar al entorno de producción. El entorno de pruebas y el entorno de producción están completamente aislados, sin afectar a los datos reales del equipo.

Progreso de la integración y cobertura de fabricantes de MES

Hasta el cierre de esta edición, se ha completado la depuración conjunta de la API con 30 fabricantes de MES, cubriendo cuatro sectores industriales: metalurgia (12), fabricación de equipos pesados (8), mecanizado (6) y logística de almacenamiento (4). Los tipos de sistemas MES integrados incluyen: sistemas MES nacionales de uso generalizado (como Yonyou U8+MES, Kingdee Cloud Galaxy MES, Digiwin MES, etc. — 14), sistemas MES verticales de sector (como MES metalúrgico, MES de procesamiento de aluminio, MES naval, etc. — 10) y sistemas MES de desarrollo propio (sistemas de gestión de taller desarrollados internamente por grandes empresas — 6).

Durante la integración, los fabricantes de sistemas MES suelen adoptar tres patrones comunes para incorporar los datos de PHM: integración de panel de alertas (los paneles de monitoreo de equipos del MES incorporan la lista de alertas de PHM, lo que permite al operador consultar las alertas de salud del puente grúa sin cambiar de sistema; aproximadamente el 70% de los clientes opta por esta opción), generación automática de órdenes de mantenimiento (el MES recibe la alerta de PHM y la utiliza para activar automáticamente el flujo de creación de la orden de mantenimiento, completando la orden con la información del equipo, la descripción de la alerta y el plan de mantenimiento recomendado; aproximadamente el 45% de los clientes opta por esta opción) y la vinculación de la salud del equipo con la planificación de la producción (el módulo de planificación del MES consulta automáticamente la puntuación de salud del equipo de PHM al asignar tareas de izaje y transporte, priorizando las tareas urgentes para los puente grúa con mayor puntuación de salud; aproximadamente el 20% de los clientes opta por esta opción). Estos tres modos son combinables y no son excluyentes entre sí.

El ciclo medio de las pruebas de integración es de 3 a 5 días laborables (desde la obtención de la documentación de la API por parte del fabricante del MES hasta la finalización de la validación de datos de extremo a extremo). El fabricante de MES más rápido completó la integración en 2 días laborables. Los problemas típicos detectados durante la fase de pruebas de integración incluyen: superación del límite de frecuencia de solicitudes a la API (se resuelve ajustando el intervalo de sondeo del sistema MES; se recomienda que el intervalo de sondeo para las interfaces de estado en tiempo real no sea inferior a 5 segundos), problemas de sincronización de datos (la hora de la alerta de PHM no coincide con la zona horaria de la orden de trabajo del MES; se resuelve devolviendo tanto la hora UTC como la hora local en los datos de alerta) y caducidad de certificados en el receptor de Webhook (se resuelve mediante la monitorización automática de la validez de los certificados en la puerta de enlace de la API y una alerta temprana con 30 días de antelación).

Escenarios de aplicación y resultados medidos

Tomemos como ejemplo una empresa metalúrgica que ya ha integrado la API de PHM. Esta empresa opera 5 puente grúa. Antes de la integración, el administrador de equipos tenía que iniciar sesión en el backend web de PHM para revisar manualmente las alertas. Una vez detectada una alerta, se rellenaba manualmente una orden de mantenimiento en papel y se entregaba al equipo de mantenimiento. El tiempo medio desde la generación de la alerta hasta la emisión de la orden era de 45 minutos. Tras la integración de la API, los eventos de alerta del sistema PHM se envían automáticamente al sistema MES de la empresa mediante Webhook. El sistema MES genera automáticamente la orden de mantenimiento según el nivel de alerta (las alertas de nivel Warning se asignan automáticamente al equipo de mantenimiento del turno de día; las alertas de nivel Critical notifican inmediatamente al ingeniero de guardia). El tiempo de generación de la orden se ha reducido a menos de 10 segundos. Las estadísticas de los 6 meses posteriores a la integración muestran que el tiempo medio de respuesta ante una parada no programada de los puente grúa (desde la ocurrencia de la avería hasta la llegada del personal de mantenimiento al sitio) se ha reducido de 85 minutos a 22 minutos, y la pérdida de capacidad de producción debida a paradas no programadas ha disminuido aproximadamente un 62%.

La apertura de la interfaz API también proporciona la base de datos necesaria para la mejora continua del sistema PHM. El modelo de alerta temprana de la puntuación de salud del puente grúa utiliza los resultados de mantenimiento retroalimentados por el sistema MES (si la avería se corresponde efectivamente con la alerta de PHM, los modelos de componentes realmente reemplazados y el tiempo de mantenimiento) para su entrenamiento iterativo, lo que mejora la precisión de alerta temprana en aproximadamente 1,5 puntos porcentuales por trimestre. Las interfaces de datos que se planea abrir en la siguiente fase incluyen: datos de consumo energético del puente grúa (consumo eléctrico en tiempo real y acumulado de los motores del Puente, el Carro y la Elevación, que permiten la comparación energética y la optimización del ahorro) y estadísticas de operaciones de izaje y transporte (número medio de operaciones diarias por puente grúa, distribución del peso izado y duración de las operaciones, que permiten el análisis de la eficiencia de la planificación de la producción). El objetivo es completar la integración con 50 fabricantes de sistemas MES antes de finales de año.

Preguntas frecuentes (FAQ)