Télémétrie chaîne du froid : passerelle Owasys Linux ouverte

La flotte exploitait environ 600 semi-remorques frigorifiques, un mélange d'unités Carrier Vector et Thermo King SLXi, tractées par un parc mixte. À bord, chaque semi portait sa propre mini-pile :

• Un contrôleur Carrier ou Thermo King parlant son propre protocole série propriétaire, couplé à l'abonnement cloud du constructeur.
• Un tracker GPS distinct sur une plateforme façon Orbcomm ou Spireon, avec sa SIM et son tableau de bord propres.
• Un capteur de porte autonome, avec encore une SIM et encore une mensualité.
• Pour les clients HACCP, un enregistreur de température qui ne parlait qu'en USB au dépôt.

Quatre boîtiers par semi. Quatre forfaits data. Quatre plateformes cloud. Quatre factures. Cinq API différentes à réconcilier dès qu'on voulait poser une question touchant plus d'un des quatre.

Lock-in fournisseur sur tout le semi. Chaque composant venait avec une redevance de plateforme. Une télémétrie dont l'opérateur payait déjà la connectivité devait faire un aller-retour par le cloud du fournisseur avant que quiconque puisse la voir. L'opérateur ne détenait jamais ses propres données. Il détenait un abonnement à une copie de celles-ci.

Fragmentation multi-protocole. Le série Carrier IntelliSet et le DSR de Thermo King sont incompatibles. Le tracker GPS parlait NMEA sur une UART séparée. Le capteur de porte était en 1-Wire. Aucun appareil du marché ne parlait nativement tout cela, la flotte restait donc à quatre boîtiers par semi pour couvrir la même surface.

Un coût par appareil qui croissait avec la flotte. Chaque semi ajoutait quatre SIM, quatre abonnements plateforme, quatre factures. Cent semi-remorques de plus, c'était quatre cents SIM de plus. Le coût de connectivité progressait quasi linéairement avec la flotte. La valeur opérationnelle, non.

Nous avons remplacé les quatre boîtiers par un seul Owasys owa4x sous Debian Linux. L'owa4x couvre, sur une seule carte, tout ce dont un semi frigorifique a besoin :

• UARTs RS-485 et RS-232, une pour le contrôleur reefer, une de réserve pour un OBC, une tablette chauffeur ou une sonde future.
• CAN J1939, pour les données moteur et châssis du tracteur.
• 1-Wire / I²C, pour le capteur de porte et les sondes montées sur le semi.
• GNSS multi-constellation interne.
• Modem cellulaire LTE Cat-4 avec double SIM.
• Entrée DC large plage automobile, boîtier étanche, plage de température complète.

Le logiciel embarqué est de nous à livrer et du client à posséder. Les données publient en MQTT vers le broker du client, il a choisi AWS IoT Core, mais le contrat reste portable s'il souhaite un jour partir.

La performance technique est dans l'application embarquée, pas dans le matériel. L'owa4x a les ports ; ce qui a rendu la consolidation possible, c'est un logiciel qui comprend chaque protocole réellement utilisé par la flotte, tournant ensemble sur une seule carte.

Implémentation : un processus Linux par protocole, isolé et redémarrable individuellement. L'adaptateur contrôleur reefer parle à la fois Carrier IntelliSet et Thermo King DSR sur la même ligne série, basculé par configuration par semi. Le processus CAN décode les PGN J1939 de n'importe quel tracteur conforme. GPS, état de porte et santé modem publient tous via la même hiérarchie de topics MQTT, schéma cohérent.

Quand le client ajoutera un nouveau modèle de reefer dans deux ans, il ne remplace pas la passerelle. Il écrit, ou commande, un adaptateur de plus.

L'ancienne pile interrogeait. Chaque appareil remontait à intervalle fixe, que quelque chose ait changé ou non, si bien que la facture cellulaire coûtait autant pour un heartbeat vide que pour un vrai événement. Sur un semi frigorifique, l'essentiel de la télémétrie ne bouge pas entre deux polls : le setpoint est stable, la porte est fermée, le camion est sur l'autoroute.

Le nouveau logiciel publie sur transitions d'état : changement de setpoint, ouverture de porte, alarme, franchissement de géo-fence, démarrage de cycle de dégivrage. Un heartbeat périodique comble les blancs pour signaler que l'appareil est en vie. Sur une fenêtre d'une heure pour un semi en mouvement, la nouvelle pile publie une poignée d'événements là où l'ancienne aurait envoyé des dizaines de payloads complets.

Cinquante semi-remorques en pilote, un mélange représentatif de marques de reefer et d'attelages tracteurs. Nous avons instrumenté l'ancienne et la nouvelle pile en parallèle pendant deux mois pour capter les dépendances silencieuses sur lesquelles les techniciens terrain comptaient. Puis déploiement complet sur six mois, dépôt par dépôt, en retirant un abonnement fournisseur par vague.

Au neuvième mois, chaque semi tournait sur Owasys et les quatre abonnements d'origine étaient supprimés. Les seuls coûts récurrents sur le semi étaient les SIM du client lui-même.

Nombre de boîtiers par semi : 4 → 1. Moins de câblage, moins de consommation, moins de modes de panne sur le terrain, installations plus rapides au dépôt.

Volume d'ingestion cloud −70%. Une publication événementielle remplace les boucles de polling de l'ancienne pile.

Dépenses SIM et connectivité −40%. Une SIM par semi au lieu de trois ou quatre, sur un mix opérateur choisi en fonction de la géographie des routes, pas du confort du fournisseur.

Frais d'abonnement plateforme : éliminés. Le cloud du constructeur reefer reste disponible pour la garantie ; le client n'y paie plus la donnée comme un chemin.

Propriété de l'IP. Logiciel embarqué, modèle de données et contrat MQTT ont été transférés à la livraison. Pas d'abonnement Melqart sur le semi.

La chaîne du froid n'a pas un grand lock-in fournisseur. Elle en a quatre : le constructeur de l'unité frigo, le fournisseur du tracker, le fabricant de capteurs auxiliaires et (souvent) la plateforme cloud rattachée à celui des trois qui était le plus pressant au moment de l'achat. Chacun facture l'accès à des données dont l'opérateur a déjà payé la connectivité.

Une passerelle Linux ouverte les lève tous les quatre en même temps. Le matériel est ouvert et soutenable, attaché à la roadmap de personne. Le logiciel appartient au client. Les protocoles restent négociables, parce que le code qui les lit est un processus Linux, pas un firmware fermé.

Le motif se reproduit dans tout marché de flotte fragmentée : location d'engins de chantier, collecte de déchets, entreprises de travaux agricoles. La chaîne du froid en est l'exemple le plus net parce que le coût par semi est le plus facile à compter.