Du Bus CAN au Cloud : Une architecture télématique pratique

Un système de télématique qui fonctionne comporte quatre pièces mobiles et une contrainte qu'il faut assumer. Les pièces : une passerelle sur la machine qui lit le bus, un logiciel edge qui transforme les trames brutes en sens, un transport qui survit à une mauvaise couverture, et un cloud qui stocke et restitue le résultat. La contrainte : la machine ne cesse pas de produire des données quand le réseau tombe, donc la passerelle doit se débrouiller seule.

Ce guide suit le chemin d'un seul signal, d'une trame CAN sur la transmission jusqu'à une ligne dans une base de données cloud, et nomme les décisions qui comptent vraiment à chaque saut. Le matériel ici est une passerelle Linux embarqué, car posséder cette couche est ce qui vous permet de modifier n'importe laquelle de ces décisions plus tard.

CAN est un bus de diffusion. Chaque contrôleur place des trames sur le fil et chaque nœud les voit ; rien ne vous est adressé. Une passerelle se branche, en général en mode écoute seule pour ne pas perturber le réseau du véhicule, et lit les trames au débit du bus, couramment 250 kbit/s ou 500 kbit/s sur les engins lourds.

Les trames brutes ne sont pas encore des données. Sur un réseau J1939 (le standard au-dessus de CAN pour les camions et les engins hors route), un identifiant 29 bits porte un PGN (Parameter Group Number), et la charge utile contient des signaux individuels adressés par SPN (Suspect Parameter Number) : régime moteur, température de liquide de refroidissement, débit de carburant, pression hydraulique. Les décoder revient à appliquer une échelle et un offset à des bits précis, la correspondance que décrit un fichier DBC. Quand une machine parle plutôt un dialecte CAN propriétaire, vous rétro-concevez ou licenciez cette correspondance. À ce stade, la passerelle filtre fermement : parmi les centaines de PGN d'un bus chargé, un cas d'usage télématique n'en veut généralement que quelques dizaines.

Le décodage donne des valeurs. Le traitement au bord décide lesquelles quittent la machine, et à quelle fréquence. Un bus à 500 kbit/s peut offrir des milliers de mises à jour de signaux par seconde ; tout envoyer par cellulaire est inutile et coûteux. La passerelle échantillonne donc et agrège : le régime moteur sort peut-être en moyenne sur une seconde, un code défaut à l'instant où il apparaît, le GPS toutes les quelques secondes, un contacteur de porte seulement au changement.

C'est aussi là que la donnée gagne sa fiabilité. Conversion d'unités, contrôles de plage qui écartent une lecture physiquement impossible, et une passe de déduplication pour qu'un signal qui n'a pas bougé ne génère pas de trafic. Deux approches se partagent la question de la bande passante. Le polling échantillonne à cadence fixe et se raisonne facilement. Le report-by-exception n'envoie que lorsqu'une valeur franchit un seuil ou change d'état, ce qui, sur des signaux industriels, réduit fortement le volume. La plupart des déploiements réels utilisent les deux, signal par signal.

La liaison est la partie que vous ne pouvez pas tenir pour acquise. Le cellulaire (LTE, de plus en plus 5G, avec LTE-M ou NB-IoT pour les capteurs à faible débit) couvre la plupart des actifs mobiles ; le Wi-Fi ou l'Ethernet conviennent aux dépôts et aux installations fixes ; le satellite est le recours là où rien d'autre ne passe. Aucune n'est continue sur le terrain, et c'est tout le problème de conception.

MQTT est le transport habituel, et pour de bonnes raisons : léger, publication-abonnement, et ses niveaux de QoS correspondent à ce dont la télématique a besoin. QoS 0 pour les échantillons à haute fréquence dont la perte est tolérable, QoS 1 pour les événements qui doivent arriver au moins une fois. La passerelle met en tampon localement (une petite file sur disque) et renvoie à la reconnexion, de sorte qu'un tunnel ou une zone blanche retarde les données au lieu de les perdre. Chaque connexion passe par TLS, idéalement avec un certificat client par appareil, afin qu'une passerelle compromise puisse être révoquée sans toucher au reste de la flotte.

De l'autre côté, un broker ou un point d'ingestion authentifie l'appareil, accepte le flux et l'écrit. Le stockage en séries temporelles épouse la forme des données ; la charge utile est en général un JSON compact ou un schéma binaire lié aux mêmes définitions de champs que celles utilisées par la passerelle, pour qu'une valeur signifie la même chose de bout en bout.

De là, les données alimentent ce que l'on voulait vraiment : tableaux de bord en direct, KPI d'utilisation et de maintenance, alertes, et une API vers les propres systèmes du client. Le détail qui décide en silence de la fiabilité de l'ensemble, c'est l'horodatage. Horodatez les mesures au bord, au moment où elles surviennent, pas à l'arrivée, sinon les données mises en tampon et rejouées après une coupure arriveront dans le désordre et fausseront chaque moyenne qui en découle.

Une démonstration sur une machine, sur un établi, est facile. Mille machines sur le terrain pendant dix ans, voilà le vrai travail, et quelques décisions déterminent laquelle vous avez construite. Faites tourner l'edge sur du Linux embarqué ouvert que vous maîtrisez, pour qu'un nouveau PGN ou un seuil modifié soit un build firmware à votre rythme, pas un ticket fournisseur. Rendez les mises à jour OTA sûres dès le premier jour : images signées et schéma de partitions A/B qui revient automatiquement en arrière si un démarrage échoue, car vous ne serez pas à côté de la passerelle quand une mise à jour tournera mal.

Concevez pour le mauvais jour, pas pour la démonstration. Supposez que le réseau tombe, que le stockage s'use et que le bus se taise, puis décidez de ce que fait la passerelle dans chaque cas avant de l'expédier. Si la couche terrain est juste, le cloud n'est presque que de la configuration. Si elle est fausse, aucune ingéniosité cloud ne récupère des données qui n'ont jamais été correctement captées.