Protokoll-Audit: BACnet, KNX, Modbus, M-Bus

Ein Netz, das antwortet, ist nicht unbedingt ein gesundes Netz

Die Werte kommen an, die Leittechnik zeigt sie an, nichts alarmiert. Trotzdem antwortet ein überlasteter Bus verzögert, ein Gateway fragt in Endlosschleife Punkte ab, die niemand ansieht, eine Automationsstation schreibt jede Sekunde einen Sollwert neu, der sich nicht geändert hat. Keiner dieser Fehler löst einen Alarm aus; man bezahlt sie mit eingefrorenen Werten, lückenhaften Verläufen und Geräten, die ohne erkennbaren Grund verschleissen. Das Protokoll-Audit macht sie sichtbar, Telegramm für Telegramm.

Die Protokolle, die wir prüfen

• BACnet/IP und BACnet MS/TP: vorhandene Geräte, tatsächlich bereitgestellte Objekte und Eigenschaften, abgeglichen mit der Datenpunktliste, der EDE-Datei und dem PICS; COV-Abonnements, Broadcasts, BBMD.
• KNX: Topologie (Bereiche, Linien, Koppler), physikalische Adressen und Gruppenadressen, Last jeder Linie, wiederholte oder unbeantwortete Telegramme.
• Modbus RTU und Modbus TCP: vorhandene Slaves, Antwortzeiten, Exceptions und Zeitüberschreitungen, Konsistenz der Registertabelle (Format, Skalierungsfaktor, Wortreihenfolge).
• M-Bus, drahtgebunden oder per Funk: vorhandene Zähler, Primär- und Sekundäradressen, Kollisionen, tatsächliche Ausleseintervalle.
• Und die Gateways dazwischen, MQTT und OPC UA eingeschlossen: Dort gehen oft Daten verloren, und dort entstehen unsinnige Abfragetakte.

Die Netzlast, gemessen statt geschätzt

Wir zeichnen den Verkehr über einen repräsentativen Zeitraum auf (Werktage, Nächte, Wochenende) und messen die Auslastung jedes Busses und jedes Segments, ihre Spitzen, die Broadcasts und die Wiederholungen. Ein serieller RS-485-Bus (BACnet MS/TP, Modbus RTU, M-Bus) hat eine feste Übertragungsrate: Bei 9600 Baud dauert das Auslesen eines Modbus-Zählers in der Grössenordnung von hundert Millisekunden. Ein Gateway, das 40 Zähler jede Sekunde abfragen soll, hält seinen Zyklus deshalb nicht ein: Er dauert in Wirklichkeit mehrere Sekunden, und die angezeigten Werte hinken nach, ohne dass es jemand ahnt. Auf KNX sind es oft zu kurze zyklische Sendeintervalle und die Leseanfragen der Visualisierung, die eine Linie überlasten (siehe Beispiel weiter unten). Eine dauerhaft belastete Linie verzögert die Telegramme, und unquittierte Telegramme werden wiederholt, was sie zusätzlich belastet. Auf IP sind es schlecht beherrschte BACnet-Broadcasts (falsch konfigurierte BBMD, wiederholte Geräteerkennungen), die das ganze Segment verstopfen.

Lese- und Schreibfrequenzen: wer was abfragt, in welchem Takt

Für jeden Teilnehmer im Netz (Leittechnik, Monitoring, Gateway, benachbarte Automationsstation) erfassen wir die gelesenen und geschriebenen Punkte, ihren Takt und ihre tatsächliche Änderung.

• Lesezugriffe: Eine Raumtemperatur, die jede Sekunde abgefragt wird, obwohl sie sich innert zehn Minuten ändert, belegt den Bus umsonst; ein stündlich ausgelesener Zähler zeigt keine Leistungsspitze. Wir vergleichen den festgestellten Takt mit dem tatsächlichen Bedarf jedes Punkts. Bei BACnet ersetzen COV-Abonnements das zyklische Abfragen vorteilhaft, sofern Inkrement und Abonnementdauer richtig eingestellt sind.
• Schreibzugriffe: der teuerste und am wenigsten sichtbare Fehler. Ein Sollwert oder Befehl, der in einer Schleife neu geschrieben wird, selbst mit identischem Wert, belastet das Netz; und wenn das Gerät ihn in einem nichtflüchtigen Speicher ablegt, verbraucht er dessen garantierte Schreibzyklen. Der Frequenzumrichter oder Regler fällt schliesslich ohne erkennbare Ursache aus. Wir ermitteln, wer was in welcher Frequenz schreibt und ob sich der Wert wirklich ändert.
• BACnet-Prioritäten: Ein Befehl, der mit hoher Priorität gesetzt und nie freigegeben wird, setzt die Regelung ausser Kraft, ohne dass etwas darauf hinweist. Wir erfassen die Prioritätentabelle jedes gesteuerten Punkts.

Mit unseren Werkzeugen, ohne den Betrieb zu stören

Das Audit stützt sich auf unsere Analysewerkzeuge: Aufzeichnung des Verkehrs, Erkennung und Inventar der Geräte, Statistiken pro Gerät, pro Punkt und pro Netzteilnehmer. Das Mithören ist passiv: Wir ändern weder die Programmierung noch die Konfiguration noch die Adressen. Aktive Abfragen (Geräteerkennung, Lesen von Eigenschaften) sind begrenzt, angekündigt und erfolgen ausserhalb heikler Betriebszeiten. Wir benötigen einen Zugang zum technischen Netz (Spiegelport am Switch oder Anschluss an den Bus), die verfügbare Dokumentation (Datenpunktliste, EDE-Datei, KNX-Projekt) und eine Ansprechperson im Betrieb.

Was Sie erhalten

• Das Inventar der tatsächlich erreichbaren Geräte und Punkte, abgeglichen mit der Dokumentation: was fehlt, was zu viel ist, was nicht übereinstimmt.
• Die gemessene Last jedes Busses und jedes Segments, mit ihren Spitzen und deren Ursache.
• Die Tabelle der Lese- und Schreibzugriffe: pro Teilnehmer und pro Punkt der festgestellte und der empfohlene Takt.
• Die Anomalien, nach Schweregrad geordnet: doppelte Adressen, stumme Geräte, Kommunikationsfehler, Schreibschleifen, nicht freigegebene Prioritäten, unkontrollierte Broadcasts.
• Die Rohaufzeichnungen in offenen Formaten, die ein anderer Dienstleister mit freien Werkzeugen lesen kann.

Nebenbei: die Angriffsfläche

BACnet/IP, Modbus TCP und KNXnet/IP ohne Absicherung authentifizieren niemanden: Wer das Netz erreicht, kann lesen und schreiben. Das Audit zeigt, welche Geräte erreichbar sind, und von wo aus. Zum normativen Rahmen: die Norm IEC 62443 und der Cyber Resilience Act.

Wann lohnt sich ein Protokoll-Audit?

• Bevor ein Monitoring oder eine neue Leittechnik an ein bestehendes Netz angeschlossen wird, um einen bereits überlasteten Bus nicht zusätzlich zu belasten.
• Wenn die Leittechnik langsam ist, Werte verliert oder eingefrorene Punkte anzeigt.
• Wenn ein Frequenzumrichter oder Regler wiederholt ohne erkennbare Ursache ausfällt.
• Vor der Erweiterung einer Anlage oder dem Hinzufügen zahlreicher Punkte.
• Bei der Übernahme einer Anlage mit unvollständiger oder unauffindbarer Dokumentation.

Zum Weiterlesen: BACnet: warum «kompatibel» nicht heisst, dass es funktioniert.