Rétrofit de surveillance de grues pour une flotte mobile mixte

Un loueur de grues européen exploite une flotte mixte de grues mobiles répartie sur trois dépôts. Les machines couvrent plusieurs générations et plusieurs OEM. Le J1939 du moteur et de la chaîne cinématique porte le diagnostic : codes défaut, niveau de carburant, températures des sous-systèmes et heures de fonctionnement. Le poids de la cellule de charge et l'inclinaison arrivent en CANopen, et là où une grue n'avait pas de signal d'inclinaison exploitable, il a fallu ajouter un capteur. Lorsqu'une grue signalait une panne, l'équipe de maintenance envoyait quelqu'un lire les codes et télécharger le datalogger sur place. L'exploitant voulait diagnostiquer avant tout déplacement, avec les mêmes valeurs de charge, d'inclinaison et d'utilisation depuis chaque châssis, sur un écran qu'il contrôle.

Deux pilotes précédents s'étaient enlisés, tous deux bâtis sur des plateformes de passerelle fermées. Les données sortaient de la cabine, puis s'arrêtaient à un portail fournisseur. Ajuster un seuil d'alerte ou redéfinir un KPI imposait une demande de modification payante et un cycle de release mesuré en mois. L'exploitant possédait les machines. Il ne possédait pas le pipeline de télémétrie, or c'est lui qui décide de ce que le gestionnaire de flotte voit réellement chaque matin.

Quatre contraintes ont façonné l'architecture, et le mandat était sans détour : aucune n'était négociable.

L'IP reste à l'exploitant. Le logiciel passerelle, le schéma de données et les tableaux de bord devaient être auditables et portables. Si Melqart se retire, l'exploitant continue d'exploiter la flotte sans changement, avec le code source, les définitions de schéma et les scripts de déploiement dans son propre dépôt.

Deux bus sur le même châssis. Les trames J1939 portent l'angle de flèche, la vitesse de levage et la charge moteur, ainsi que les codes défaut, le niveau de carburant, les températures des sous-systèmes et les heures de fonctionnement. Le CANopen porte la cellule de charge et le capteur d'inclinaison, ajouté là où la grue n'en avait pas. Les deux devaient se résoudre en un enregistrement normalisé par grue par seconde, position GPS comprise, sous un schéma canonique unique, pour qu'une grue à flèche treillis de 2008 et une grue tout-terrain actuelle rapportent l'utilisation de la même façon.

Le datalogger doit être accessible. Chaque grue conserve un datalogger embarqué détaillé. Le lire imposait un déplacement en cabine, la passerelle devait donc le rendre téléchargeable à distance.

La connectivité n'est pas acquise. Carrières et chantiers en intérieur tombent à 2G ou sans signal pendant des heures. Le pipeline devait mettre en tampon sur la passerelle, expédier l'arriéré à la reconnexion et ne jamais perdre une trame en silence pendant un levage. Un trou de couverture ne peut pas devenir un trou dans l'enregistrement du levage.

La pile déployée est volontairement ennuyeuse, et c'est l'objectif. Chaque grue embarque une passerelle Owasys qui termine le J1939 et le CANopen, avec le GPS à bord. Un petit daemon d'acquisition lit les deux bus, applique une table d'étalonnage par unité (chaque cellule de charge a son propre offset et sa propre étendue) et écrit un enregistrement normalisé dans un buffer time-series local avant que le moindre réseau ne soit sollicité. Le buffer, et non le broker, fait office de registre de données à l'edge. La même passerelle donne accès au datalogger embarqué, que la maintenance télécharge depuis le bureau.

De là, un publisher MQTT expédie les enregistrements via cellulaire à un broker hébergé par l'exploitant dans son propre VPC. MQTT transporte les enregistrements à la seconde avec un quality-of-service réglé pour qu'une session interrompue reprenne depuis le buffer plutôt que de perdre ce qui était en transit. Un worker stream distribue les données dans deux directions : vers une base Postgres dotée de l'extension TimescaleDB pour les tableaux de bord, et vers un object store pour les archives brutes de long terme. Aucun portail SaaS dans le chemin. Chaque composant tourne dans le compte de l'exploitant, et chaque enregistrement a un schéma documenté et un propriétaire nommé.

Les mises à jour OTA arrivent via un canal signé. L'exploitant peut figer une version de firmware ou faire tourner un dépôt entier depuis sa propre console sans nous appeler. Un échange de passerelle prend à un ingénieur terrain une quinzaine de minutes, grâce à une image pré-flashée et à un faisceau de câbles qui reproduit le connecteur de service OEM, si bien que l'unité se branche sur les broches existantes au lieu d'un travail de soudure.

Le déploiement a couru comme trois dépôts en séquence, jamais comme un seul big-bang sur la flotte.

Dépôt A (semaines 1–3) : douze grues sur trois générations OEM. L'objectif était de prouver les tables d'étalonnage, le comportement du buffer et la liaison cellulaire sous des levages réels, pas sur un banc. Tout a tourné instrumenté. Chaque trame perdue était journalisée et revue quotidiennement, et les rares trouvées venaient du câblage, pas du pipeline.

Dépôt B (semaines 4–7) : trente grues, dont les unités sans signal d'inclinaison exploitable. Elles ont reçu un capteur d'inclinaison ajouté sur le réseau CANopen, étalonné avec le mécanicien chef de l'exploitant dans la boucle par rapport à des positions de flèche connues. Aucune IP n'a quitté l'exploitant.

Dépôt C (semaines 8–11) : le reste de la flotte. À ce stade, le travail était mécanique : monter, flasher, étalonner, passer à la suite. Les équipes dépôt mettaient en service les nouvelles unités elles-mêmes, et notre rôle est passé de l'installation à la réponse à la question occasionnelle.

L'exploitant gère son propre tableau de bord KPI, les chiffres ci-dessous sont donc les siens. Nous les rapportons tels que communiqués douze semaines après la mise en service du dernier dépôt.

• Temps jusqu'à la première télémétrie sur une grue fraîchement rétrofitée : moins de 30 minutes, étalonnage compris.
• Perte de trame en conditions 2G ou sans service : 0 % sur une fenêtre de 24 heures, grâce à la mise en tampon locale et à la reprise à la reconnexion.
• Taux de capture des événements de levage, avec poids cellule de charge, inclinaison et angle de flèche corrélés à un même horodatage : ~99,3 % sur l'ensemble de la flotte.
• Temps pour expédier un nouveau seuil d'alerte à toute la flotte : le même jour, sans demande de modification fournisseur.

Pour la maintenance, le changement le plus important se trouve hors de cette liste. Les codes défaut, les températures des sous-systèmes et le niveau de carburant sont lus à distance, et le datalogger est téléchargé depuis le bureau avant que quiconque ne décide de se déplacer.

Publier la KPI d'utilisation de flotte revient à l'exploitant, pas à nous. La note de l'équipe dispatch est celle qui a le plus compté pour nous : « le chiffre qu'on lit à l'écran est le chiffre qu'on croit au point du matin. » Cette phrase reformule le mandat : un flux auquel ils croient, parce qu'ils possèdent la façon dont il est construit.

Ce projet a façonné notre offre de diagnostic de grues à distance, mais il n'y a pas de kit standard derrière. Il y a un schéma d'architecture, un choix matériel précis, un schéma normalisé et une mission qui a remis l'ensemble de la pile à l'équipe de l'exploitant. Le prochain exploitant qui demandera un rétrofit de grues recevra un programme façonné par sa flotte et ses contraintes, pas un re-skin de celui-ci. Le mélange de bus, le nombre de dépôts et les trous de couverture seront différents, et la conception découle de ces faits.

Ce que l'exploitant a gardé après le transfert : l'IP de la passerelle, le schéma, les tableaux de bord, les runbooks et le droit de partir. Ce qu'il n'a pas gardé : une dépendance envers un fournisseur quelconque, nous compris.