Rétrofit de monitoring 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 : certaines exposent un bus CAN J1939 standard, d'autres uniquement des sorties analogiques de cellule de charge et d'inclinaison, et une poignée parle un dialecte CAN propriétaire sans documentation publique. L'exploitant voulait les mêmes valeurs de charge, d'inclinaison et d'utilisation depuis chaque châssis, sur un écran qu'il contrôle, sans lier la flotte à un produit télémétrie OEM ni à un silo cloud unique.

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.

Trois 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 protocoles sur le même châssis. Sur les unités récentes, les trames J1939 portent l'angle de flèche, la vitesse de levage et la charge moteur via CAN. Les unités plus anciennes n'ont pas de bus exploitable : le poids cellule de charge et l'inclinaison arrivent en tensions analogiques depuis le câblage des capteurs. Les deux devaient se résoudre en un enregistrement normalisé par grue par seconde, 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.

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 Linux ouverte Owasys qui termine J1939 sur CAN ainsi que les entrées analogiques de charge et d'inclinaison. Un petit daemon d'acquisition lit les deux sources, 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.

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 à CAN propriétaire. Nous avons rétro-conçu les trames pertinentes avec le mécanicien chef de l'exploitant dans la boucle, en décodant l'angle de flèche et les signaux de levage par rapport à des positions physiques connues, puis nous avons appris le dialecte au daemon d'acquisition. Aucun OEM contacté, et 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 au buffering local 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.

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.

Il n'y a, au bout du compte, pas de « système de monitoring de grues » à acheter. Il y a un schéma d'architecture, un choix matériel précis, un schéma normalisé et un engagement 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 protocoles, 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.