Les données d'exploitation accumulées par le système de gestion prédictive de la santé (PHM) d'un pont roulant ne deviennent un véritable hub de données intégré aux décisions de planification de production que lorsqu'elles sont connectées au système d'exécution de la fabrication (MES) de l'atelier et à la plateforme de gestion supérieure. Kelude vient d'ouvrir l'API RESTful de son système PHM pour ponts roulants. À la date de rédaction, l'interfaçage est opérationnel avec 30 éditeurs MES, couvrant trois grandes catégories de systèmes : MES métallurgique, MES de fabrication discrète et WMS de stockage. Grâce à cette ouverture, les données de statut en temps réel, les événements d'alarme et les recommandations de maintenance du pont roulant peuvent être directement transmis à la plateforme de gestion de production existante du client, sans que l'opérateur ait à basculer entre plusieurs systèmes. Cet article présente le système de manière structurée selon quatre axes : spécification technique de l'API, procédure d'interfaçage, scénarios d'application typiques et résultats de l'intégration.

Architecture de l'API PHM et modèle de données

L'API PHM ouverte respecte la spécification OpenAPI 3.0, adopte une architecture RESTful et prend en charge deux formats de sérialisation : JSON et Protocol Buffers. Les interfaces sont réparties en cinq catégories selon le type de ressource, couvrant l'ensemble des capacités de données du système PHM pour ponts roulants.

API de statut en temps réel (Realtime Status API) : fournit une consultation en un clic de l'état de fonctionnement actuel du pont roulant. Principaux endpoints : GET /api/v1/crane/{craneId}/status (renvoie les paramètres de fonctionnement courants — coordonnées X/Y du pont, hauteur de levage, vitesse de translation, courant moteur, état du frein, lecture du limiteur de surcharge, etc., soit 36 champs au total, avec une fréquence d'actualisation d'une seconde), GET /api/v1/crane/{craneId}/health (renvoie le score de santé de l'équipement, un indice de santé de 0 à 100 calculé par fusion multidimensionnelle de paramètres, mis à jour toutes les 5 minutes) et GET /api/v1/crane/{craneId}/alerts (renvoie la liste des alarmes non traitées, filtrable par niveau de gravité et type d'alarme).

API de données historiques (History API) : fournit des requêtes par lots sur les données d'exploitation et l'historique des alarmes. Endpoints : GET /api/v1/crane/{craneId}/timeseries (interrogation des données de séries temporelles historiques d'un paramètre donné sur une plage temporelle, avec export continu jusqu'à 30 jours, période d'échantillonnage configurable en trois niveaux : 1 seconde / 10 secondes / 1 minute), GET /api/v1/crane/{craneId}/alerts/history (interrogation de la liste des événements d'alarme historiques, avec horodatage de déclenchement et de résolution, type d'alarme, niveau de gravité et état de traitement) et GET /api/v1/crane/{craneId}/maintenance (interrogation de l'historique de maintenance de l'équipement, avec type d'intervention, date, contenu et exécutant). Cette API est principalement utilisée par le système MES pour générer des rapports d'analyse OEE et planifier les calendriers de maintenance.

API de notification d'alarme (Alert Webhook API) : permet à la plateforme MES de s'abonner aux événements d'alarme du système PHM via Webhook. Le client configure les règles de notification dans l'interface Web PHM (URL de destination, seuil de gravité et fréquence d'envoi). Lorsqu'un nouvel événement d'alarme est généré, le système PHM envoie automatiquement une requête POST à l'URL Webhook configurée, le corps de la requête étant un objet JSON décrivant l'événement. Le Webhook intègre un mécanisme de relance : en cas d'échec de la première tentative, une nouvelle tentative est effectuée après 30 secondes, jusqu'à 3 fois maximum ; si les trois tentatives échouent, une notification par e-mail est envoyée à l'administrateur pour traitement manuel. La latence médiane de notification est de 5 secondes (entre la détection de l'anomalie par le PHM et la réception du message par le MES du client).

API de gestion des équipements (Device Management API) : fournit les opérations CRUD sur les informations de base des ponts roulants. Elle permet d'ajouter un nouvel équipement (POST /api/v1/crane, avec génération automatique d'un identifiant unique et des paramètres de configuration initiaux), de mettre à jour la configuration (PATCH /api/v1/crane/{craneId}, pour modifier les seuils d'alarme, la fréquence d'échantillonnage, etc.), de consulter la liste des équipements (GET /api/v1/cranes, filtrable par atelier, type d'équipement et état de fonctionnement) et de supprimer un équipement (DELETE /api/v1/crane/{craneId}, avec confirmation requise). Cette API permet au système MES du client d'effectuer automatiquement l'enregistrement d'un nouveau pont roulant dans le système PHM, sans intervention manuelle sur l'interface PHM.

API de modèles et de diagnostic (Model API) : fournit la gestion des modèles de diagnostic IA et la consultation des résultats. Endpoints : GET /api/v1/model/{modelId}/info (consultation des informations d'un modèle de diagnostic — numéro de version, date de déploiement, modèles de ponts roulants pris en charge et indicateurs de précision), POST /api/v1/crane/{craneId}/diagnose (déclenchement d'un diagnostic de santé immédiat pour un pont roulant donné, renvoyant l'état de santé de chaque sous-système et les mesures de maintenance recommandées) et GET /api/v1/crane/{craneId}/diagnose/history (consultation de la liste des rapports de diagnostic historiques). La Model API permet au système de dispatching MES du client d'interroger l'état de santé du pont roulant avant la planification de la production, évitant ainsi d'affecter des tâches à un équipement en mauvais état.

Solution technique d'interfaçage et certification de sécurité

L'authentification de l'API PHM repose sur le flux d'octroi de justificatifs client OAuth 2.0 (Client Credentials Grant). Lors du premier interfaçage, le système MES du client demande un identifiant client (client_id) et une clé secrète (client_secret) via la plateforme développeur PHM, puis obtient un jeton d'accès (access_token) via l'endpoint POST /oauth/token. La période de validité du jeton est de 24 heures par défaut ; après expiration, un jeton d'actualisation (refresh_token) est nécessaire pour le renouveler. Les limites de débit sont les suivantes : l'API de statut en temps réel accepte au maximum 6 000 requêtes par heure (soit environ 1,67 requête par seconde en moyenne), l'API de données historiques 360 requêtes par heure, tandis que les API de notification d'alarme et de diagnostic ne sont pas soumises à limitation. Le temps de réponse de l'API est inférieur à 500 ms au 99e percentile (hors latence réseau lente).

La transmission de données est chiffrée en TLS 1.3. La passerelle API est déployée sur Alibaba Cloud API Gateway, avec protection WAF (pare-feu applicatif web) et anti-DDoS. Les journaux de requêtes enregistrent l'horodatage, l'identifiant client, le chemin de la requête, le code de réponse et la durée d'exécution ; ils sont conservés pendant 180 jours. Le client peut consulter en libre-service, via la plateforme développeur, les statistiques d'appels API (volume journalier, taux de succès, temps de réponse moyen, etc.). Une sandbox est mise à disposition : le client peut y développer et tester ses interfaces avec des données simulées avant de basculer en environnement de production. Les environnements sandbox et production sont totalement isolés, garantissant l'intégrité des données réelles des équipements.

Avancement de l'interfaçage et couverture des éditeurs MES

À la date de rédaction, l'interfaçage API est opérationnel avec 30 éditeurs MES, répartis sur quatre secteurs : métallurgie (12 éditeurs), fabrication d'équipements lourds (8), usinage mécanique (6) et logistique de stockage (4). Les types de systèmes MES interfacés comprennent : les MES nationaux courants (tels que Yonyou U8+MES, Kingdee Cloud Galaxy MES, Digiwin MES, etc. — 14 éditeurs), les MES verticaux (MES métallurgique, MES de transformation de l'aluminium, MES naval, etc. — 10 éditeurs) et les MES développés en interne (systèmes de gestion d'atelier conçus par de grandes entreprises — 6 éditeurs).

Lors de l'intégration des données PHM dans les systèmes MES des différents éditeurs, on observe trois modes d'utilisation courants : l'intégration par tableau de bord d'alertes (les alertes PHM sont intégrées au tableau de surveillance des équipements du MES, permettant à l'opérateur de consulter les alertes de santé du pont roulant sans basculer vers le système PHM — environ 70 % des clients optent pour cette solution), la génération automatique d'ordres de maintenance (le MES reçoit l'alerte PHM et déclenche automatiquement la création d'un ordre de maintenance, avec renseignement automatique des informations d'équipement, de la description de l'alerte et du plan de maintenance recommandé — environ 45 % des clients), et la corrélation entre santé d'équipement et ordonnancement (le module d'ordonnancement du MES consulte automatiquement le score de santé de l'équipement PHM lors de l'affectation des tâches de levage et transport, en priorisant les tâches urgentes vers les ponts roulants présentant le meilleur score — environ 20 % des clients). Ces trois modes peuvent être combinés sans conflit.

La durée moyenne des tests d'intégration est de 3 à 5 jours ouvrés (de l'obtention de la documentation API auprès de l'éditeur MES jusqu'à la validation complète des données de bout en bout). L'éditeur MES le plus rapide a réalisé l'intégration en 2 jours ouvrés. Les problèmes typiques rencontrés lors des tests d'intégration incluent : dépassement de la limite de fréquence des requêtes API (résolu en ajustant l'intervalle d'interrogation du MES — il est recommandé de ne pas descendre en dessous de 5 secondes pour les interfaces d'état en temps réel), problèmes de synchronisation temporelle (décalage de fuseau horaire entre l'horodatage des alertes PHM et celui des ordres de travail MES — résolu en renvoyant simultanément l'heure UTC et l'heure locale dans les données d'alerte), et expiration des certificats Webhook (résolu grâce à la surveillance automatique de la validité des certificats via la passerelle API et une alerte précoce de 30 jours).

Scénarios d'application typiques et résultats mesurés

Prenons l'exemple d'une entreprise métallurgique ayant intégré l'API PHM. Cette entreprise exploite 5 ponts roulants. Avant l'intégration, l'administrateur des équipements devait se connecter manuellement au back-office Web PHM pour consulter les alertes, puis remplir un ordre de maintenance papier à transmettre à l'équipe de maintenance. Le délai moyen entre la génération de l'alerte et la transmission de l'ordre était de 45 minutes. Après l'intégration de l'API, les événements d'alerte PHM sont automatiquement poussés vers le système MES via Webhook. Le MES génère automatiquement l'ordre de maintenance en fonction du niveau d'alerte (les alertes de niveau Warning sont automatiquement affectées à l'équipe de maintenance de jour, tandis que les alertes de niveau Critical déclenchent une notification immédiate de l'ingénieur de permanence). Le délai de génération de l'ordre est désormais inférieur à 10 secondes. Les statistiques sur 6 mois après l'intégration montrent que le temps de réponse moyen aux arrêts non planifiés des ponts roulants (du moment de la panne à l'arrivée sur site des techniciens) est passé de 85 à 22 minutes, et la perte de capacité de production due aux arrêts non planifiés a été réduite d'environ 62 %.

L'ouverture de l'interface API a également fourni une base de données précieuse pour l'amélioration continue du système PHM — le modèle d'alerte précoce basé sur le score de santé de l'équipement est itérativement entraîné à partir des résultats de maintenance remontés par le MES (correspondance effective entre la panne et l'alerte PHM, modèles de composants réellement remplacés, durée de l'intervention), ce qui améliore la précision de l'alerte précoce d'environ 1,5 point par trimestre. Les prochaines interfaces de données prévues incluent : les données de consommation énergétique des ponts roulants (consommation électrique en temps réel et cumulée du Moteur de Levage, du Pont et du Chariot, permettant l'analyse comparative et l'optimisation énergétique) et les statistiques d'activité de levage et transport (nombre quotidien de cycles de levage par pont roulant, répartition des masses levées et durée des opérations, pour l'analyse de l'efficacité de l'ordonnancement de production). L'objectif est de finaliser l'intégration avec 50 éditeurs MES d'ici la fin de l'année.

Questions fréquentes (FAQ)