Audit de protocoles : BACnet, KNX, Modbus, M-Bus

Un réseau qui répond n'est pas forcément un réseau sain

Les valeurs arrivent, la supervision affiche, rien n'alarme. Pourtant, un bus saturé répond avec retard, une passerelle interroge en boucle des points que personne ne consulte, un automate réécrit chaque seconde une consigne qui n'a pas changé. Aucun de ces défauts ne déclenche d'alarme ; ils se paient en valeurs figées, en historiques troués et en équipements qui s'usent sans raison apparente. L'audit de protocoles les rend visibles, trame par trame.

Les protocoles que nous auditons

• BACnet/IP et BACnet MS/TP : équipements présents, objets et propriétés réellement exposés, comparés à la liste de points, au fichier EDE et au PICS ; abonnements COV, diffusions (broadcast), BBMD.
• KNX : topologie (zones, lignes, coupleurs), adresses physiques et adresses de groupe, charge de chaque ligne, télégrammes répétés ou sans réponse.
• Modbus RTU et Modbus TCP : esclaves présents, temps de réponse, exceptions et délais dépassés, cohérence de la table de registres (format, facteur d'échelle, ordre des mots).
• M-Bus, filaire ou radio : compteurs présents, adresses primaires et secondaires, collisions, intervalles de relève effectifs.
• Et les passerelles entre eux, MQTT et OPC UA compris : c'est souvent là que se perdent les données et que naissent les cadences absurdes.

La charge du réseau, mesurée et non estimée

Nous enregistrons le trafic sur une période représentative (jours ouvrables, nuits, week-end) et mesurons l'occupation de chaque bus et de chaque segment, ses pointes, les diffusions et les répétitions. Un bus série RS-485 (BACnet MS/TP, Modbus RTU, M-Bus) a un débit fixe : à 9600 bauds, relever un compteur Modbus prend de l'ordre d'une centaine de millisecondes. Une passerelle réglée pour interroger 40 compteurs chaque seconde ne tient donc pas son cycle : il dure en réalité plusieurs secondes, et les valeurs affichées ont un retard que personne ne soupçonne. Sur KNX, ce sont souvent les envois cycliques trop rapprochés et les lectures de la visualisation qui saturent une ligne (voir l'exemple plus bas) ; une ligne chargée en permanence retarde les télégrammes, et ceux qui restent sans acquittement sont répétés, ce qui la charge encore davantage. Sur IP, ce sont les diffusions BACnet mal maîtrisées (BBMD mal configurés, découvertes répétées) qui encombrent tout le segment.

Fréquences de lecture et d'écriture : qui interroge quoi, à quelle cadence

Pour chaque client du réseau (supervision, monitoring, passerelle, automate voisin), nous relevons les points lus et écrits, leur cadence et leur variation réelle.

• Lectures : une température ambiante scrutée chaque seconde alors qu'elle évolue en dix minutes occupe le bus pour rien ; un compteur relevé toutes les heures ne montre aucune pointe de puissance. Nous comparons la cadence constatée au besoin réel de chaque point. En BACnet, les abonnements COV remplacent avantageusement la scrutation, à condition que l'incrément et la durée d'abonnement soient correctement réglés.
• Écritures : c'est le défaut le plus coûteux et le moins visible. Une consigne ou une commande réécrite en boucle, même à valeur identique, charge le réseau ; et lorsque l'équipement l'enregistre en mémoire non volatile, elle en consomme les cycles d'écriture garantis. Le variateur ou le régulateur finit par tomber en panne sans cause apparente. Nous identifions qui écrit, quoi, à quelle fréquence, et si la valeur change vraiment.
• Priorités BACnet : une commande forcée à une priorité élevée et jamais relâchée neutralise la régulation sans que rien ne l'indique. Nous relevons le tableau des priorités de chaque point commandé.

Avec nos outils, sans perturber l'exploitation

L'audit s'appuie sur nos outils d'analyse : capture du trafic, découverte et inventaire des équipements, statistiques par équipement, par point et par client du réseau. L'écoute est passive : nous ne modifions ni la programmation, ni la configuration, ni les adresses. Les interrogations actives (découverte, lecture de propriétés) sont limitées, annoncées et réalisées hors des périodes sensibles. Il nous faut un accès au réseau technique (port miroir sur le commutateur ou raccordement au bus), la documentation disponible (liste de points, fichier EDE, projet KNX) et un interlocuteur côté exploitation.

Ce que vous obtenez

• L'inventaire des équipements et des points réellement accessibles, confronté à la documentation : ce qui manque, ce qui est en trop, ce qui ne correspond pas.
• La charge mesurée de chaque bus et de chaque segment, avec ses pointes et leur origine.
• Le tableau des lectures et des écritures : par client et par point, la cadence constatée et la cadence recommandée.
• Les anomalies classées par gravité : doublons d'adresse, équipements muets, erreurs de communication, écritures en boucle, priorités non relâchées, diffusions non maîtrisées.
• Les captures brutes, dans des formats ouverts, lisibles par un autre prestataire avec des outils libres.

L'exposition, au passage

BACnet/IP, Modbus TCP et KNXnet/IP sans sécurisation n'authentifient personne : quiconque atteint le réseau peut lire et écrire. L'audit montre quels équipements sont joignables, et depuis où. Pour le cadre normatif : la norme CEI 62443 et le Cyber Resilience Act.

Quand faire auditer ses protocoles ?

• Avant de raccorder un monitoring ou une nouvelle supervision à un réseau existant, pour ne pas charger davantage un bus déjà saturé.
• Quand la supervision est lente, perd des valeurs ou affiche des points figés.
• Quand un variateur ou un régulateur tombe en panne à répétition sans cause apparente.
• Avant d'étendre une installation ou d'y ajouter de nombreux points.
• À la reprise d'une installation dont la documentation est incomplète ou introuvable.

À lire : BACnet, pourquoi « compatible » ne veut pas dire que ça va marcher.