NMEA 2000 : des données du bus aux ordres de travail

Ce que transporte réellement le bus NMEA 2000

Sur un navire correctement équipé, la température d'eau de refroidissement du moteur principal, la pression d'huile, le compteur d'heures, le niveau des caisses et la tension des batteries circulent déjà en permanence. Elles transitent par le bus NMEA 2000 et s'affichent sur un écran multifonction à la timonerie. Le plus souvent, elles s'arrêtent là.

Personne ne les enregistre. Personne ne les compare au relevé de la semaine précédente. Le mécanicien note le compteur d'heures à la main, le recopie dans un tableur au retour d'escale, et la vidange se déclenche sur cette valeur recopiée. La donnée juste existait à bord depuis le début. Elle n'est simplement jamais arrivée jusqu'au plan de maintenance.

Cet article traite cet écart : ce que le bus transporte réellement, ce qu'on peut en tirer pour la maintenance, et — c'est au moins aussi important — où cette approche fonctionne et où elle ne suffit pas.

Un bus CAN, une dorsale, des connecteurs en T

Le NMEA 2000, souvent abrégé N2K, est une norme de communication marine publiée par la National Marine Electronics Association. Elle repose sur le bus CAN (Controller Area Network), le même principe de réseau série différentiel que l'automobile et le poids lourd utilisent depuis des décennies. L'intérêt du CAN à bord est simple : une paire torsadée, une alimentation, un blindage, et n'importe quel équipement branché dessus peut émettre et écouter sans qu'un calculateur central ait à arbitrer.

Physiquement, l'installation ressemble toujours à la même chose. Une dorsale traverse le navire de la timonerie au compartiment moteur. Sur cette dorsale viennent se piquer des connecteurs en T, un par appareil, avec une antenne de dérivation de longueur limitée. Aux deux extrémités de la dorsale, une résistance de terminaison de 120 ohms. Sans les deux terminaisons, le bus fonctionne parfois quand même : mal, par intermittence, avec des trames perdues qu'on met des semaines à diagnostiquer.

Trois points de vigilance reviennent systématiquement en intervention.

• La longueur cumulée des dérivations est plafonnée. Multiplier les Té improvisés pour ajouter un capteur finit par dégrader tout le réseau.
• Le bus est alimenté. Le budget de courant se calcule ; un capteur de plus n'est pas toujours neutre.
• Chaque appareil réclame une adresse. Un conflit d'adresse se traduit par un instrument qui disparaît de l'écran de façon apparemment aléatoire.

Ces détails ne sont pas anecdotiques. La fiabilité de tout ce qui suit dépend d'un bus propre. Un réseau mal terminé produit des trous dans l'historique, et un historique troué ne permet aucune analyse de tendance.

Les PGN sont des messages, pas des capteurs

Sur le bus circulent des messages normalisés identifiés par un numéro : le PGN, pour Parameter Group Number. Un PGN n'est ni un capteur ni une valeur unique. C'est une enveloppe qui contient plusieurs champs. C'est la confusion la plus fréquente quand on commence à travailler sur du N2K, et elle a deux conséquences pratiques.

D'abord, une grandeur peut ne pas être publiée du tout. Si le moteur n'a pas de sonde de pression de carburant, le champ correspondant part avec la valeur « non disponible ». Le message arrive, le champ est vide. Ensuite, ce n'est pas parce qu'un PGN circule que la mesure est fiable : une sonde de niveau à flotteur dans une caisse à gasoil reste une sonde de niveau à flotteur, quel que soit le protocole qui transporte sa valeur.

Les PGN utiles à la maintenance

Pour un plan de maintenance, une poignée de PGN suffit. Voici ceux qui portent l'essentiel, avec leur contenu réel.

Trois précisions comptent davantage que la liste elle-même.

Le compteur d'heures est dans le PGN 127489, et non dans un message dédié. Il arrive dans le même flux que les températures et les pressions, ce qui est plutôt une bonne nouvelle : une seule source alimente à la fois le compteur qui déclenche le plan de maintenance et la surveillance d'état.

Le régime moteur est dans le PGN 127488, pas dans le 127489. C'est toute la distinction entre rapid update et dynamic : le régime change vite et se publie souvent, les températures évoluent lentement et se publient moins.

Tension alternateur et tension du parc de batteries ne sont pas la même grandeur. La tension mesurée par le calculateur moteur remonte dans le 127489. La tension d'un parc mesurée par un shunt ou un chargeur remonte dans le 127508, complétée le cas échéant par l'état de charge du 127506. Confondre les deux revient à surveiller le mauvais circuit.

Dernier avertissement, valable pour toute la liste : les constructeurs n'exposent pas tous la même chose. Beaucoup de moteurs passent par une passerelle propriétaire du motoriste, et il faut vérifier au cas par cas, bus branché et moteur tournant, quels champs arrivent réellement remplis. C'est un travail d'une demi-journée à quai qu'aucune documentation ne remplace.

À qui s'adresse le NMEA 2000, et où il s'arrête

Il faut le dire franchement, parce que la promesse est régulièrement survendue : le NMEA 2000 s'arrête là où commence la salle des machines d'un navire de commerce.

Le N2K est né pour l'électronique de passerelle et la motorisation de taille modeste. Il est pertinent, et souvent excellent, sur :

• la plaisance professionnelle et le yachting jusqu'aux unités de taille moyenne ;
• la pêche côtière et les petites unités à moteur rapide ;
• les navires de servitude : vedettes de pilotage, navettes à passagers, bateaux-écoles, embarcations de servitude portuaire ;
• toute unité dont les moteurs principaux disposent d'un calculateur électronique relié à une passerelle constructeur.

Sur un ferry, un navire de recherche, un CTV ou un SOV de l'éolien offshore, la réalité est différente. Les moteurs de forte puissance, les groupes électrogènes, les séparateurs et les tableaux principaux ne parlent pas NMEA 2000. La donnée vient d'ailleurs.

• J1939 : le protocole CAN du poids lourd et de l'industrie diesel, très répandu sur les moteurs à injection électronique de moyenne puissance. C'est d'ailleurs ce que convertissent les passerelles J1939 vers N2K que l'on trouve sur les unités mixtes.
• Modbus, en RTU sur RS-485 ou en TCP : le langage habituel des automates, des tableaux électriques, des variateurs, des séparateurs et des groupes.
• Le système d'alarme et de surveillance du bord, qui centralise déjà les points machine et dispose en général d'une interface d'export.

Le raisonnement de maintenance conditionnelle est rigoureusement identique dans les trois cas : une grandeur mesurée, un seuil, un historique, un ordre de travail. Seule la couche de transport change. Ce qui compte pour un armateur, c'est de ne pas retenir un outil de gestion de maintenance qui ne sache lire qu'un seul protocole. Sur une flotte mixte — quelques vedettes en N2K, deux navires dont les points machine sortent du système d'alarme en Modbus — l'unité doit se faire dans la GMAO, pas dans le câblage.

De la passerelle au cloud : la chaîne de données

Le bus reste à bord. Pour que la donnée serve un plan de maintenance de flotte, il faut la sortir du navire. C'est le rôle de la passerelle : un boîtier raccordé à la dorsale par un connecteur en T, qui écoute les PGN et les republie en TCP/IP vers un serveur.

Ce qu'il faut chercher dans une passerelle

Plutôt qu'une marque, voici les caractéristiques à vérifier avant d'acheter. La liste tient sur une page et évite l'essentiel des mauvaises surprises.

• Certification NMEA 2000. Un boîtier certifié respecte le budget de courant, l'isolation et la gestion d'adresse. C'est ce qui garantit qu'il ne viendra pas perturber les instruments de navigation.
• Isolation galvanique entre le bus et l'alimentation du boîtier. Sur une coque en acier ou en aluminium, c'est ce qui évite d'injecter une boucle de masse dans un réseau de navigation.
• Écoute passive. La passerelle doit pouvoir se contenter d'écouter, sans jamais émettre sur le bus. Tout boîtier qui écrit sur un réseau de navigation est un risque à justifier.
• Mémoire locale et rejeu. Si la liaison tombe, le boîtier doit continuer à enregistrer et renvoyer l'historique horodaté au retour du lien. Sans cela, c'est la donnée acquise en mer qui est perdue, c'est-à-dire précisément celle qui compte.
• Horodatage à la source. Les points doivent être datés à bord et non à l'arrivée sur le serveur, faute de quoi un rejeu après quarante-huit heures de coupure produit un historique faux.
• Filtrage et échantillonnage configurables. Personne n'a besoin de la position à dix hertz pour faire de la maintenance. Réduire à la source, c'est réduire la facture de données satellitaires.
• Format de sortie documenté et non chiffré par le fabricant, sans quoi vous êtes captif du boîtier et de son éditeur.
• Alimentation et indice de protection compatibles avec l'emplacement réel, qui sera rarement l'armoire sèche prévue au plan.

Nous ne recommandons pas de modèle particulier : le marché bouge, et le bon choix dépend surtout du motoriste et de la liaison disponible à bord. Ces huit critères, eux, ne bougent pas.

Latence, débit et cache embarqué

Une chaîne de données maritime n'est pas une chaîne de données à terre. Trois différences structurent tout le reste.

Le lien tombe. C'est la norme, pas l'exception. Une vedette de pilotage sort de couverture cellulaire, un fileyeur travaille à cinquante milles, une antenne perd le cap au demi-tour. Toute architecture qui suppose une liaison permanente produira des trous. Le cache embarqué n'est pas une option de confort : c'est le composant qui décide si votre historique sera exploitable ou non.

Le débit se paye. Remonter chaque trame brute d'un bus N2K représente plusieurs centaines de mégaoctets par jour et par navire. Remonter une moyenne par minute sur quinze grandeurs, plus les événements de franchissement de seuil, représente quelques mégaoctets. Le second suffit à toute la maintenance conditionnelle.

La latence utile dépend de l'usage. Une chute de pression d'huile doit être traitée en secondes — et elle l'est déjà, par l'alarme moteur, à bord, sans passer par un serveur. Une remontée cloud n'a pas vocation à remplacer la sécurité machine. Elle sert à autre chose : conserver, comparer, décider à froid. Pour suivre une dérive de température sur trois semaines, une remontée par minute est largement suffisante, et une remontée horaire l'est souvent aussi.

Autrement dit : la protection immédiate reste à bord et reste câblée. Le cloud sert la maintenance, pas la sécurité machine. Confondre les deux mène à des architectures fragiles et à des attentes déçues.

Le compteur d'heures automatique change le plan de maintenance

De toutes les données du bus, la plus utile n'est pas la plus spectaculaire. C'est le compteur d'heures.

Un plan de maintenance moteur est presque toujours déclenché sur compteur : vidange à 250 heures, jeu aux soupapes à 1 000, injecteurs à 3 000. Tant que le compteur est relevé à la main, trois choses arrivent. On relève tard, et l'échéance passe. On recopie de travers, et un chiffre erroné se propage dans tout l'historique. Ou on ne relève pas du tout pendant une période chargée, et personne ne rattrape le trou.

Quand le compteur remonte automatiquement depuis le PGN 127489, l'échéance se déclenche sur la valeur réelle, le jour où elle est atteinte. Les compteurs d'heures Smart Sailors alimentent directement les tâches du plan, et l'ordre de travail se génère sans que personne n'ait à y penser. C'est peu spectaculaire. C'est pourtant ce qui produit le plus d'effet la première année.

Le même mécanisme vaut pour les caisses. Le PGN 127505 alimente le suivi des niveaux, ce qui permet de rapprocher consommation réelle et heures de fonctionnement : la base de tout suivi de consommation de carburant sérieux.

Un compteur fiable, c'est une preuve devant l'inspecteur

Il existe une seconde raison, moins souvent évoquée, de vouloir un compteur d'heures juste : la conformité.

Quand un inspecteur de société de classification ou un contrôleur de l'État du port ouvre votre plan de maintenance, il ne se contente pas de constater qu'une tâche existe. Il vérifie qu'elle a été exécutée à l'échéance prévue. Sur une tâche déclenchée au compteur, cela revient à prouver deux choses : quelle était la valeur du compteur à la date d'exécution, et que cette valeur n'a pas été saisie après coup pour justifier l'intervention.

Un relevé automatique horodaté à la source répond à la question sans discussion possible. Un carnet manuscrit recopié dans un tableur y répond mal, et c'est exactement le type de faiblesse qui transforme une visite de routine en observation. Pour les navires soumis à un système de maintenance planifiée approuvé par la société de classification, la traçabilité de l'exécution n'est pas un confort administratif : c'est la condition du maintien de l'approbation. Le raisonnement vaut aussi pour le journal machine numérique, dont les heures de fonctionnement doivent concorder avec celles du plan. Deux compteurs qui divergent, et c'est la crédibilité de l'ensemble du dossier qui se discute.

Des seuils aux ordres de travail

Une fois les grandeurs remontées et historisées, la mécanique est simple : une règle, un seuil, une durée de confirmation, une action.

La durée de confirmation est le paramètre que tout le monde oublie. Une température qui dépasse un seuil pendant une seconde, c'est du bruit de mesure ou une trame corrompue. La même température maintenue trente secondes, c'est un événement. Toute règle utile s'écrit donc sous la forme « grandeur, comparaison, seuil, pendant durée ».

Le tableau ci-dessous donne une trame de départ. Les valeurs sont des exemples d'illustration, pas des consignes. Les seuils réels se lisent dans la documentation du motoriste, se recoupent avec les réglages de l'alarme machine existante, et se calibrent avec l'expérience du chef mécanicien sur ce navire précis. Un moteur suralimenté travaillant à 88 °C nominal et un moteur atmosphérique à 78 °C n'ont pas le même seuil, et personne à terre ne peut le décider à leur place.

La dernière ligne mérite un mot. Compter les heures ne suffit pas toujours : mille heures au ralenti en attente de pilotage et mille heures à pleine charge n'usent pas un moteur de la même façon. Croiser le compteur d'heures avec le temps passé dans chaque plage de régime donne une périodicité de plan nettement plus juste. C'est faisable dès lors qu'on historise le 127488 en même temps que le 127489.

Une fois l'ordre de travail créé, tout se joue sur ce qui arrive à l'équipage. Un OT qui reste dans un serveur ne sert à rien. Un ordre de travail consultable sur mobile en salle des machines, avec la procédure et la référence de la pièce, se solde. C'est le maillon qui décide si toute la chaîne aura servi à quelque chose.

Pourquoi les alertes finissent par être ignorées

C'est le point que la plupart des projets sous-estiment, et c'est celui qui les tue.

Une alerte n'a de valeur que si elle est rare. Un équipage qui reçoit quatre notifications par jour pendant deux semaines pour des dépassements sans conséquence arrête de les lire. Pas par négligence : par économie d'attention. Et le jour où l'alerte réelle arrive, elle se noie dans le bruit. Cette dérive est connue de longue date dans les postes de contrôle machine, et elle se reproduit à l'identique dès qu'on branche une remontée cloud sans discipline.

Ce qui produit du bruit, dans l'ordre de fréquence constatée :

• des seuils copiés d'un navire à l'autre — ce qui est nominal sur une vedette ne l'est pas sur un chalutier ;
• l'absence de durée de confirmation, qui transforme chaque pointe de mesure en événement ;
• l'absence de gestion des états transitoires : un moteur qui démarre a une pression d'huile basse et une eau froide, et une règle qui ne tient compte ni du régime ni du temps écoulé depuis le démarrage se déclenchera à chaque appareillage ;
• l'absence d'hystérésis : une valeur qui oscille autour du seuil génère une alerte à chaque passage, il faut un seuil de retour à la normale distinct du seuil de déclenchement ;
• l'absence d'accusé de réception : une alerte qu'on ne peut ni acquitter ni commenter revient indéfiniment.

La méthode qui fonctionne est ennuyeuse mais fiable. Démarrer en observation seule pendant quatre à six semaines, sans aucune notification, uniquement en enregistrant. Regarder ensuite les valeurs réellement atteintes en exploitation normale, placer les seuils au-dessus de cette enveloppe, et n'activer les notifications que sur trois ou quatre grandeurs. On en ajoute ensuite, une à la fois. Une flotte qui n'a activé que la pression d'huile et la température d'eau, mais dont l'équipage réagit à chaque alerte, est très en avance sur une flotte qui surveille quarante points que plus personne ne regarde.

Un dernier réflexe utile : compter les alertes comme on compte les pannes. Un tableau de bord qui affiche le nombre d'alertes émises, le nombre d'alertes acquittées et le nombre d'alertes suivies d'une intervention réelle indique immédiatement si le paramétrage tient la route. Ce ratio a toute sa place à côté des indicateurs de maintenance classiques.

Une alerte de seuil n'est pas une analyse de tendance

Il faut être clair sur ce que la surveillance par seuil apporte, et sur ce qu'elle n'apporte pas.

Un seuil est rétrospectif. Quand la température le franchit, le problème est déjà là. On gagne le temps d'une réaction, ce qui est déjà beaucoup, mais on n'a rien anticipé.

Une tendance est prospective. Elle ne compare pas une valeur à un seuil, elle compare une valeur à son propre historique dans des conditions équivalentes. La question n'est plus « la température dépasse-t-elle 95 °C » mais « à 1 400 tr/min et 18 °C d'eau de mer, ce moteur tourne-t-il trois degrés plus chaud qu'il y a deux mois ». Trois degrés ne déclenchent aucune alarme. C'est pourtant là qu'est le signal.

Faire de la tendance impose des contraintes que la surveillance par seuil n'a pas :

• un historique long et continu, donc un cache embarqué qui fonctionne réellement ;
• une normalisation par les conditions : régime, charge, température d'eau de mer, température ambiante. Comparer des relevés pris à des régimes différents ne produit que du bruit ;
• une base de comparaison propre, c'est-à-dire une période de référence pendant laquelle on sait que la machine était en bon état ;
• la trace des interventions. Une baisse de température après un arrêt technique n'est pas une amélioration spontanée : c'est l'effet du nettoyage de l'échangeur, et l'historique doit le dire.

C'est aussi la limite du bus. Le NMEA 2000 donne des grandeurs globales et lentes : température, pression, régime, niveau. Il ne dit rien de l'état d'un roulement, d'un balourd d'accouplement, d'un défaut d'alignement de ligne d'arbre ou d'un point chaud dans un tableau électrique. Pour cela, il faut des méthodes dédiées — analyse vibratoire et thermographie — et l'analyse des huiles, qui reste le meilleur rapport information sur coût pour un diesel marin. La donnée du bus est un socle continu et déjà payé. Elle ne remplace pas ces mesures : elle indique quand les faire.

Ce que ça change, concrètement

Nous ne publierons pas de pourcentage de réduction de pannes : ces chiffres ne veulent rien dire hors du contexte d'une flotte précise. Le raisonnement, lui, se tient, et chacun peut le refaire avec ses propres coûts.

Prenez un moteur principal immobilisé. Le coût réel n'est presque jamais celui de la pièce. C'est une escale non planifiée : le navire ne travaille pas, l'équipage est payé, un créneau de chantier se cherche dans l'urgence, la pièce part en fret express, et pour une unité sous contrat il y a une journée qui ne sera pas facturée. Additionnez ces lignes pour votre exploitation, une seule fois. Le chiffre obtenu est votre coût de référence.

Comparez-le maintenant à l'autre branche. Une dérive de température détectée trois semaines plus tôt, c'est une intervention préparée : le navire est à quai de toute façon pour son escale technique, la pièce est commandée en fret normal, le travail se fait entre deux marées, personne ne dort à l'hôtel. C'est exactement la différence entre une intervention à quai et un remorquage.

Le même raisonnement s'applique aux échéances ratées, et il joue dans les deux sens. Une vidange faite cent heures trop tard n'apparaît sur aucun tableau de bord, jusqu'au jour où l'analyse d'huile revient chargée. Et une vidange faite cent heures trop tôt, répétée sur une flotte de huit navires à deux moteurs chacun, représente un budget d'huile, de filtres et de main-d'œuvre dépensé pour rien. Un compteur juste supprime les deux erreurs.

Enfin, il y a le coût qu'on ne voit jamais dans un budget : le temps passé à chercher l'information. Combien d'heures par mois un superintendant passe-t-il à réclamer par courriel des relevés que le bus produit déjà en continu ? Cette ligne n'existe dans aucun compte d'exploitation, et c'est souvent la première à disparaître.

C'est cette bascule que décrit le passage de la maintenance curative à la maintenance conditionnelle : on ne supprime pas les interventions, on choisit quand elles ont lieu.

Par où commencer

Un projet de ce type se rate presque toujours de la même façon : on branche tout, on active tout, on abandonne au bout de deux mois. L'ordre suivant limite ce risque.

1. Vérifier le bus avant tout le reste. Terminaisons, tension, longueur des dérivations, conflits d'adresse. Une demi-journée à quai.
2. Relever ce qui arrive réellement. Brancher un enregistreur, lister les PGN présents et les champs effectivement remplis, moteur tournant et moteur arrêté. Vous saurez alors ce que vous pouvez surveiller, ce qui est rarement ce qu'annonce la brochure.
3. Fiabiliser le compteur d'heures en premier. Une seule grandeur, mais celle qui déclenche le plan. C'est le gain le plus rapide et le plus solide : le plan de maintenance préventive devient exact sans effort supplémentaire.
4. Enregistrer sans alerter pendant quatre à six semaines, pour connaître l'enveloppe normale du navire.
5. Activer trois seuils, pas trente. Pression d'huile, température d'eau, et une troisième grandeur choisie avec le chef mécanicien.
6. Faire le point à trois mois avec l'équipage : combien d'alertes émises, combien de pertinentes, combien d'ordres de travail réellement soldés. Ajuster, puis élargir.
7. Étendre à la flotte seulement quand un navire fonctionne, en conservant des seuils propres à chaque unité.

Sur une flotte de pêche comme sur un yacht en gestion professionnelle, le facteur limitant n'est jamais la technologie du bus. C'est la discipline de paramétrage et la qualité du retour de l'équipage. Le NMEA 2000 fournit une matière première continue, fiable et déjà payée. Ce qu'on en tire dépend entièrement de la rigueur du plan de maintenance qui la reçoit.