Système de commande et Jumeau Numérique pour Pont Roulant

Dans l'industrie de la fabrication de grues, les systèmes de commande et les plateformes numériques deviennent le critère décisif de la compétitivité des produits. Alors que la plupart des entreprises utilisent encore des solutions « standardisées » associant des API génériques à des IHM tierces, Kelude Industries Lourdes a choisi une voie technologique radicalement différente — du matériel de base aux algorithmes de haut niveau, de l'acquisition de données au Jumeau Numérique, tout est développé en interne. Il ne s'agit pas d'embellir la liste des fournisseurs, mais parce que les solutions génériques atteignent une limite de performance intrinsèque face aux conditions de service complexes des grues.

Cet article analyse la logique technologique de la solution développée par Kelude sous trois angles : l'architecture intégrée matériel-logiciel du système de commande, les capacités de modélisation et de prédiction de la plateforme Jumeau Numérique, et la solution d'intégration de la plateforme de données. Pour chaque volet, nous établissons une comparaison horizontale avec les solutions génériques en termes de coût, de performance et d'extensibilité.

Système de commande propriétaire : PC industriel + Linux temps réel + algorithmes internes en remplacement des API génériques

Plateforme Jumeau Numérique : Unity 3D + WebGL, modèle réduit POD, prédiction LSTM

La plateforme Jumeau Numérique de Kelude Industries Lourdes n'a pas pour vocation d'« afficher des effets 3D » — sa valeur fondamentale repose sur trois piliers : visualiser, calculer avec précision, anticiper. La logique sous-jacente de la plateforme peut se résumer à une boucle fermée : « données → modèle → inférence → décision ».

Couche de visualisation : interaction WebGL basée sur Unity 3D. Kelude a choisi Unity 3D comme moteur de rendu 3D et compile les scènes au format WebGL. L'utilisateur n'a besoin d'installer aucun logiciel client : il accède au modèle numérique tridimensionnel complet de la grue via un simple navigateur. Ce modèle n'est pas une simple présentation CAO — il reflète en temps réel tous les états de mouvement de l'équipement : position du mouvement de translation du pont, position du chariot, Hauteur de Levage, angle de balancement de la charge. Toutes ces données sont poussées en temps réel depuis la plateforme de données vers le front-end via WebSocket, avec une fréquence de rafraîchissement de 20 fps (résolution de 50 ms) et une latence visuelle inférieure à 100 ms. L'opérateur ouvre son navigateur dans la salle de Commande au sol et voit exactement la même scène 3D que celle de la Cabine de Conduite.

Pour garantir un chargement rapide de la scène 3D dans le navigateur, l'équipe de R&D a réalisé une série d'optimisations de performance : le nombre de polygones du modèle a été réduit de 8 millions (CAO d'origine) à 150 000 (en conservant toutes les caractéristiques extérieures et en supprimant les détails internes invisibles), les textures utilisent le format compressé KTX2 pour réduire l'occupation mémoire GPU, le contrôleur d'animation adopte un modèle à machine d'états plutôt qu'une animation image par image, et le chargement de la première image est maîtrisé en moins de 4 secondes (dans des conditions réseau de 100 Mbit/s).

Couche d'inférence physique : le modèle réduit POD pour résoudre le défi de la simulation en temps réel. La plus grande difficulté technique du Jumeau Numérique n'est pas de « paraître réaliste », mais de « calculer vite ». Un modèle par éléments finis typique de Poutre Principale d'un Pont Roulant de 100 tonnes peut compter plus de 300 000 degrés de liberté. La résolution d'un seul cas de charge statique avec un logiciel FEA commercial (tels que ANSYS ou Abaqus) prend 3 à 5 minutes — ce qui est totalement inacceptable pour une inférence en temps réel.

La solution adoptée par l'équipe de Kelude est le modèle réduit POD (Proper Orthogonal Decomposition, décomposition orthogonale aux valeurs propres). L'idée centrale est simple : la distribution des Contraintes dans la structure pour la grande majorité des conditions de service peut être approximée par une combinaison linéaire d'un petit nombre de « modes de base ». L'équipe de R&D a préalablement calculé avec ANSYS la réponse de Contrainte sur l'ensemble de la structure pour 1 000 cas de charge typiques (combinant différentes positions de Charge, différentes intensités de Charge et différentes positions du chariot). Une décomposition en valeurs singulières (SVD) a ensuite permis d'extraire les 15 modes de base à plus forte contribution énergétique — leur énergie cumulée atteint 99,2 %, ce qui signifie que ces 15 fonctions de base peuvent reconstruire la quasi-totalité de l'information contenue dans les 1 000 cas de charge.

En fonctionnement en ligne, le système n'a plus qu'à effectuer une interpolation et une combinaison linéaire dans cet espace de dimension 15, en fonction des conditions de Charge mesurées en temps réel. Le temps de calcul d'un champ de Contraintes est ainsi réduit à 15–30 ms, avec un contrôle de la perte de précision inférieur à 5 %. Cela signifie que le système Jumeau Numérique peut suivre chaque opération de Levage de la grue et actualiser en temps réel la carte de chaleur du champ de Contraintes complet de la Poutre Principale — l'opérateur ne voit plus à l'écran quelques valeurs isolées de jauges de Contrainte, mais une vue d'ensemble de la poutre indiquant « où s'appliquent les efforts, où se concentre la Fatigue ».

Données de déploiement mesurées : sur 3 Ponts Roulants de 100 tonnes, chaque unité est équipée de 16 points de mesure de Contrainte par fibre optique (FBG) et de 4 points de mesure d'accélération, avec une fréquence d'acquisition de données de 1 Hz. Le modèle POD effectue une inférence complète du champ de Contraintes chaque seconde et superpose le résultat sur le modèle Unity 3D. Le système fonctionne en continu et de manière stable depuis plus de 14 mois (au 30 juin 2026), avec plus de 37 millions d'inférences cumulées, sans aucune divergence de modèle ni anomalie de calcul.

Couche de prédiction : modèle de séries temporelles LSTM pour la prédiction de durée de vie utile restante. La capacité avancée du Jumeau Numérique n'est pas de « comprendre le présent », mais d'« anticiper l'avenir ». Kelude a superposé, sur les données de champ de Contraintes issues du modèle POD, un module de prédiction de la durée de vie en fatigue basé sur un réseau LSTM (Long Short-Term Memory).

Les caractéristiques d'entrée du modèle LSTM comprennent : la Contrainte équivalente maximale en temps réel de la Poutre Principale issue de l'inférence POD, le nombre de cycles de contrainte (extrait par comptage rainflow), la distribution de la moyenne et de l'amplitude du spectre de charge, le temps de fonctionnement cumulé de l'équipement, et la Température Ambiante. La sortie est : la durée de vie résiduelle en fatigue des zones critiques de la Poutre Principale (exprimée en nombre de cycles) et un niveau d'alerte précoce (quatre niveaux : vert / jaune / orange / rouge). Le modèle utilise une entrée par fenêtre glissante de 720 pas de temps (correspondant à 12 heures de données historiques) pour prédire l'accumulation de Fatigue sur les 7 prochains jours.

Source de données pour l'entraînement : avant la mise en service, l'équipe de R&D a effectué un entraînement hors ligne du modèle LSTM en utilisant 12 mois de données d'exploitation historiques provenant de 3 Prototypes d'essai (comprenant 1,2 million d'échantillons valides). Après la mise en service réelle, le modèle est automatiquement mis à jour de manière incrémentale toutes les 24 heures, intégrant les nouvelles données dans l'ensemble d'entraînement afin de s'adapter au Vieillissement de l'équipement et aux évolutions des conditions de service. Lors de la validation en exploitation réelle d'octobre 2025 à juin 2026, l'erreur absolue moyenne en pourcentage (MAPE) entre la prédiction à 7 jours de l'accumulation de Fatigue de la Poutre Principale et la valeur mesurée était de 8,3 %. L'anticipation offerte par la prédiction est suffisante pour permettre à l'équipe de maintenance d'organiser les interventions avant un arrêt non planifié.

En outre, la plateforme intègre également un module de prédiction des vibrations pour la Boîte de vitesses du mécanisme de levage et le roulement de moteur. Grâce à l'extraction de caractéristiques temps-fréquence du signal d'accélération (FFT + spectre d'enveloppe), combinée au modèle LSTM, il est possible d'alerter 7 à 14 jours à l'avance sur les défauts de la Bague Intérieure / Bague Extérieure des Roulements. Sur les 8 équipements déployés, le modèle a émis 47 alertes précoces au total, dont 43 ont été confirmées comme de véritables défauts lors d'inspections à l'arrêt sur site, soit un taux de précision de 91,5 %, avec un délai moyen d'anticipation de 11,3 jours.

Plateforme de données : acquisition OPC UA/MQTT, base de données de séries temporelles, passerelle API

Le système de commande produit les données, le Jumeau Numérique les consomme — le pont entre les deux est la plateforme de données. L'architecture de la plateforme de données de Kelude suit une conception en trois couches « acquisition en périphérie → agrégation → stockage → service de sortie », chaque couche ayant une logique de sélection technologique claire.

Couche d'acquisition en périphérie : OPC UA en priorité, MQTT en complément. Côté équipement, la passerelle périphérique d'acquisition « KruEdge » développée en interne par Kelude fonctionne sur le PC industriel situé dans l'Armoire de Commande et communique avec le runtime KruControl via le protocole OPC UA. Le choix d'OPC UA est motivé par des raisons précises : il prend nativement en charge la modélisation des données (transmettant non plus des données brutes, mais des données « sémantiques » — par exemple « Contrainte équivalente maximale de la Poutre Principale / MPa / point de mesure FBG-03 »), la sécurité par chiffrement (certificats X.509 mutuels + chiffrement de transport AES-256) et un mécanisme de renvoi automatique des données historiques en cas d'interruption. Les données collectées par la passerelle comprennent trois catégories : les variables d'état de l'équipement (vitesse, Courant, Couple, position des trois mécanismes : Levage / mouvement de translation du pont / chariot), les variables de sécurité (capteur de surcharge, Fin de Course, état du Frein) et les variables de santé structurelle (Contrainte FBG, accélération, température), soit au total environ 600 points de données, avec une fréquence d'acquisition configurable de 1 à 100 Hz.

Pour les équipements anciens ne prenant pas en charge OPC UA (par exemple les modèles antérieurs à 3 ans, dont certains utilisent le Protocole Modbus RTU), la passerelle périphérique assure la liaison via un module d'adaptation de protocole Modbus vers OPC UA. En outre, pour un petit nombre de données de télémétrie à faible exigence de temps réel (telles que la position GPS, la température et l'humidité ambiantes, les statistiques de consommation d'énergie), le protocole MQTT est utilisé avec un rapport périodique de 5 minutes, afin de réduire la charge de données sur la couche de commande.

Couche de stockage : architecture de stockage hybride basée sur une base de données de séries temporelles. Les 600 points de données sont collectés en continu à une fréquence de 1 à 100 Hz. Le volume de données généré par un seul équipement en une journée est d'environ 1,5 à 5 Go (selon la densité d'acquisition). Si 50 % des équipements vendus par Kelude (environ 200 unités) sont tous connectés à la plateforme de données, le volume d'écriture annuel atteindra 100 à 360 To. Une base de données relationnelle traditionnelle ne peut manifestement pas supporter une telle charge d'écriture.

La solution de stockage de Kelude est une architecture hybride à deux niveaux : le premier niveau est un cache local — chaque passerelle périphérique d'équipement est équipée d'un SSD NVMe de 256 Go, mettant en cache l'intégralité des données des 30 derniers jours (environ 45 à 150 Go par équipement). En cas d'interruption réseau, les données ne sont pas perdues et sont automatiquement renvoyées après la restauration. Le deuxième niveau est une base de données de séries temporelles cloud — utilisant la solution open source TimescaleDB (extension de base de données de séries temporelles basée sur PostgreSQL), déployée sur des serveurs privés. La structure des tables suit un modèle en colonnes larges « ID d'équipement + horodatage + ID de point de mesure », avec une granularité de partitionnement temporel de 72 heures. Performances d'écriture mesurées : un nœud unique (8 cœurs, 32 Go) peut traiter de manière stable 240 000 lignes d'écriture par seconde, avec une latence de requête au 95e percentile inférieure à 50 ms (pour une requête sur l'ensemble des données d'un seul équipement sur une période de 30 jours).

Pour maîtriser les coûts de stockage des données historiques, l'équipe a également conçu une stratégie de compression et d'agrégation des données : les données brutes sont conservées pendant 90 jours (pour la recherche de défauts et l'entraînement du modèle) ; les données de 90 jours à 1 an sont sous-échantillonnées à une valeur par minute (agrégation par moyenne + maximum + minimum) ; les données de plus d'un an sont sous-échantillonnées à une valeur par heure. Le volume total de stockage, comprenant l'ensemble des données et les deux niveaux de sous-échantillonnage, ne représente que 12 à 15 % du volume des données brutes.

Couche de service : passerelle API unifiée. Une fois les données stockées, qui les consomme ? Le front-end du Jumeau Numérique a besoin de données d'état en temps réel, le Web a besoin de courbes de tendance historiques, l'application terminal mobile a besoin de notifications d'alerte, et les systèmes tiers (tels que le MES ou l'ERP du client) ont besoin d'interfaces de connexion — chaque consommateur a des exigences différentes en termes de format de données, de protocole de transmission et de droits d'accès. Kelude a développé sa propre passerelle API « KruGateway » pour résoudre ce problème.

KruGateway, développé sur la base de la passerelle open source Kong, intègre des fonctionnalités personnalisées dédiées aux environnements industriels : prise en charge de l'accès unifié aux quatre protocoles OPC UA, MQTT, HTTP REST et gRPC, avec conversion interne systématique au format JSON standard avant distribution aux consommateurs. La gestion des droits au niveau de la passerelle s'articule selon un contrôle tridimensionnel « dimension appareil + dimension données + dimension fonction » : un client peut, par exemple, n'être autorisé à consulter que ses 10 appareils (dimension appareil), ne disposer que d'un accès en lecture aux données d'état sans pouvoir modifier les paramètres de contrôle (dimension fonction), et, parmi ces données d'état, ne pas avoir accès aux données des capteurs de sécurité (dimension données). La passerelle intègre également un contrôle de flux de données et un mécanisme d'accélération par cache — pour les requêtes à haute fréquence du front-end du Jumeau Numérique (rafraîchissement à 20 fps), la passerelle met automatiquement en cache les données instantanées des 3 dernières secondes, évitant ainsi qu'un rendu front-end ne nécessite une interrogation de la base de données à chaque fois.

Au 30 juin 2026, KruGateway traite en moyenne environ 2,8 millions d'appels API par jour, avec un temps de réponse au 95e percentile inférieur à 15 ms et un taux de disponibilité mensuel de 99,97 %.

Comparaison globale avec les solutions génériques : coût, performance, extensibilité

Les trois volets techniques ci-dessus détaillent chacun la logique sous-jacente de la solution développée en interne par Kelude. Mais la décision finale en matière de sélection technique n'appartient pas à l'équipe R&D, mais à la direction — qui ne se pose qu'une seule question : en quoi cette solution sur mesure est-elle réellement supérieure à une solution générique ? L'investissement en ressources humaines et matérielles supplémentaire en vaut-il la peine ?

Le tableau ci-dessous propose une comparaison quantitative globale selon trois dimensions : coût, performance et extensibilité :

De la comparaison ci-dessus se dégage une logique claire : le « plafond » de la solution API générique n'est pas une question de prix, mais d'architecture. Sa puissance de calcul, son temps réel, son ouverture et son extensibilité la cantonnent au niveau du « contrôle logique programmable », incapable de porter des capacités supérieures telles que les algorithmes intelligents, le Jumeau Numérique et l'analyse des mégadonnées industrielles. La solution IPC + Linux temps réel de Kelude consiste essentiellement à « rétrograder » un PC industriel performant au rôle de Contrôleur — en échangeant une puissance de calcul excédentaire contre la flexibilité de développement et l'espace d'extension futur.

Bien entendu, cette solution a aussi son coût. Le plus important est l'investissement en R&D — du lancement du projet en 2021 à la production en série en 2024, la plateforme KruControl a cumulé plus de 32 millions de CNY de développement, soit plus de 120 hommes-années. Pour une entreprise manufacturière de taille moyenne réalisant un chiffre d'affaires de plusieurs centaines de millions de CNY, c'est un chiffre « bien visible » dans les états financiers. Le deuxième coût est la gestion de la chaîne d'approvisionnement — l'approvisionnement des composants du PC industriel, le délai de fabrication des cartes mères personnalisées (12 à 16 semaines en moyenne), l'adaptation et la validation du noyau Linux temps réel, tout cela est bien plus complexe que l'achat d'un API prêt à l'emploi.

Mais la direction de Kelude est claire sur cette orientation technologique : au point de basculement où l'industrie de la grue passe de la « concurrence par l'échelle » à la « concurrence par la technologie », le « suffisant » de l'API générique devient « insuffisant ». Plutôt que d'attendre que les concurrents s'emparent du marché haut de gamme avec leurs solutions propriétaires, mieux vaut consacrer trois ans à creuser son propre fossé technologique.

Conclusion

Revenons au titre de cet article : bien plus que des grues. Kelude Industries Lourdes fabrique des grues depuis vingt ans, mais ce qui distingue véritablement cette entreprise de ses pairs, ce n'est pas la capacité de levage, ni la complexité des commandes qu'elle peut traiter, mais ce qui se passe « là où l'on ne voit pas » à l'intérieur de la grue — chaque ligne de code du système de commande, chaque fonction de base du Jumeau Numérique, chaque pipeline de données de la plateforme de données — tout est développé en interne.

La solution API générique est certes mature et fiable, mais ses limites définissent le plafond de performance de la grue. Kelude a choisi de briser ce plafond avec l'IPC + Linux temps réel, de transformer le Jumeau Numérique d'outil de démonstration en outil d'ingénierie grâce au modèle réduit POD, et de convertir les données des équipements en actifs d'entreprise avec sa plateforme de données propriétaire. Ces trois éléments combinés constituent la base technologique de Kelude Industries Lourdes dans le domaine du Pont Roulant Intelligent.

Ce chemin n'a pas été rapide — du lancement en 2021 à la production en série en 2024, il a fallu plus de trois ans ; il n'a pas été bon marché — 32 millions de CNY d'investissement en R&D n'est pas une somme négligeable pour une entreprise manufacturière. Mais l'équipe de Kelude partage une conviction : le fossé technologique est le seul actif que la guerre des prix ne peut pas éroder. Ce que la solution API générique ne peut pas faire, la solution propriétaire de Kelude le peut — c'est là que réside la différenciation.

Questions fréquentes

Q : Quelle est la différence fondamentale entre le système de commande IPC + Linux temps réel développé en interne par Kelude et un API générique ?
A : La différence fondamentale réside dans l'ouverture de l'architecture du système et le plafond de puissance de calcul. Le matériel et le logiciel d'un API générique sont définis de manière fermée par le fabricant ; l'utilisateur ne peut programmer que dans le cadre imposé (schéma à contacts, langage SCL, etc.), sans pouvoir exécuter d'algorithmes avancés développés en interne, et la puissance de calcul est limitée par des processeurs ARM basse consommation. La solution IPC de Kelude utilise des processeurs Intel x86, offrant une puissance de calcul 8 à 10 fois supérieure à celle d'un API haut de gamme, avec un noyau Linux temps réel PREEMPT_RT permettant d'exécuter du code C++/Python arbitraire dans l'espace utilisateur, avec prise en charge du déploiement conteneurisé et de la Mise à niveau à distance OTA. En résumé, l'API est un « automate programmable industriel », la solution IPC est un « ordinateur industriel programmable » — le premier assure le contrôle, le second réalise la fusion contrôle + calcul + extension.

Q : Qu'est-ce que le modèle réduit POD et pourquoi est-il si important pour le Jumeau Numérique ?
A : Le POD (Proper Orthogonal Decomposition, décomposition orthogonale aux valeurs propres) est une méthode de réduction de modèle pilotée par les données. En effectuant une décomposition en valeurs singulières sur un grand volume de données précalculées, il extrait les « modes fondamentaux » à plus forte teneur énergétique, compressant une résolution FEA haute dimension qui prendrait plusieurs minutes en un calcul d'interpolation basse dimension de quelques dizaines de millisecondes. Pour le Jumeau Numérique, sans la réduction POD, la simulation de la Contrainte en temps réel serait impossible — on ne peut pas demander à l'opérateur d'attendre 3 à 5 minutes qu'une FEA se termine pour voir le résultat. La solution de Kelude reconstruit 99,2 % de l'information de 1 000 conditions de service avec 15 modes fondamentaux, pour un temps de calcul en ligne de seulement 15 à 30 ms.

Q : Comment la plateforme de données de Kelude traite-t-elle les données massives des équipements ?
A : Elle adopte une architecture à trois niveaux. Couche périphérique (passerelle KruEdge) : chaque équipement met en cache localement 30 jours de données complètes (environ 45 à 150 Go), avec mise en cache automatique en cas d'interruption réseau et retransmission après rétablissement. Couche de stockage : basée sur la base de données de séries temporelles TimescaleDB, un nœud unique traite 240 000 lignes d'écriture par seconde, les données brutes sont conservées 90 jours puis automatiquement sous-échantillonnées à des granularités minute et heure. Couche de service : la passerelle API KruGateway fournit une sortie unifiée, prenant en charge les quatre protocoles OPC UA, MQTT, HTTP REST et gRPC, avec un traitement moyen de 2,8 millions d'appels API par jour et un temps de réponse au 95e percentile inférieur à 15 ms. La gestion des droits est contrôlée selon trois dimensions « équipement + données + fonction », garantissant la sécurité des données dans un scénario multi-locataires.

Q : Cette solution propriétaire convient-elle à tous les clients ?
A : Elle s'adresse actuellement principalement aux clients et aux scénarios d'application exigeant un haut niveau d'intelligence, tels que la métallurgie, le Port, l'énergie nucléaire et d'autres secteurs nécessitant la téléopération, la gestion de la santé des équipements ou une maintenance optimisée. Pour les scénarios génériques ne nécessitant que des fonctions de Levage de base, Kelude continue de proposer une gamme de produits standard basée sur des solutions API éprouvées. La solution propriétaire et la solution générique coexistent — la première crée la différenciation et construit la barrière technologique, la seconde couvre le marché de base sensible au rapport qualité-prix. Les deux approches ne sont pas mutuellement exclusives ; elles constituent une stratégie produit segmentée destinée à différentes catégories de clients.