Vom Modbus-Register zur Managemententscheidung

Angenommen, wir lesen aus einem Modbus-Register eines industriellen Leistungsmessgeräts den folgenden Rohwert aus:

Register: 40001
Wert:     23871

Sind wir damit mit der industriellen Digitalisierung fertig?

Wir haben noch nicht einmal richtig angefangen.

23871 ist nicht mehr als eine Ziffernfolge. Damit sich eine Entscheidung darauf stützen lässt, müssen wir wissen, was sie bedeutet, woher sie stammt, wann sie gültig war, wie verlässlich sie ist, wozu sie gehört, im Vergleich wozu sie als auffällig gilt und was geschehen soll, wenn tatsächlich ein Problem vorliegt.

Verfolgen wir den gesamten Weg der Daten.

1. Das Register richtig auslesen

Anhand der Modbus-Dokumentation ist Folgendes festzulegen:

• der verwendete Funktionscode;
• die tatsächliche Registeradresse;
• der Datentyp;
• die Interpretation mit oder ohne Vorzeichen;
• die Byte- und Wortreihenfolge;
• der Skalierungsfaktor;
• die Maßeinheit;
• die Gültigkeits- und Fehlerkennungen.

Schon die Schreibweise 40001 kann zu Missverständnissen führen. Manche Dokumentationen verwenden eine für Menschen gedachte Nummerierung, andere eine bei null beginnende Protokolladresse. Ein einziger Adressversatz kann dazu führen, dass wir nicht die Leistung, sondern ein benachbartes Register auslesen.

Angenommen, laut Dokumentation ist der Wert eine vorzeichenlose 16-Bit-Ganzzahl mit einer Skalierung von 1 W. Dann gilt:

23871 → 23.871 W → 23,871 kW

Jetzt hat der Wert eine physikalische Bedeutung. Einen geschäftlichen Kontext hat er aber noch nicht.

2. Geräteidentität und Zeitstempel

Die Daten müssen einem konkreten Zähler und Messpunkt zugeordnet werden. Die IP-Adresse oder die Modbus-Unit-ID (Geräteadresse) reichen dafür nicht aus, denn sie können sich ändern oder an mehreren Standorten mehrfach vorkommen.

Benötigt werden eine stabile Geräte- und Messpunktkennung sowie ein verlässlicher Zeitstempel. Das System muss außerdem unterscheiden können,

• wann die Messung stattgefunden hat;
• wann das Gateway sie ausgelesen hat;
• wann sie im zentralen System eingegangen ist.

Nach einem Netzwerkausfall können zuvor gepufferte Daten verspätet eintreffen. Wird nur der Eingangszeitpunkt gespeichert, verschiebt sich das historische Bild, und die Regeln bewerten die Daten möglicherweise falsch.

3. Datenqualität und Gültigkeit

Nicht jede ausgelesene Zahl ist eine echte Messung. Es kann sich um den letzten bekannten Wert nach einem Kommunikationsfehler handeln, um einen Überlauf, um einen Zustand während des Gerätestarts oder um einen dokumentierten Fehlercode.

Deshalb kann den Daten ein Qualitätskennzeichen beigefügt werden:

quality: good | uncertain | bad
source: live | buffered | estimated

Eine Geschäftsregel darf eine verifizierte Live-Messung und einen geschätzten, unsicheren Wert nicht gleich behandeln. In einem Abrechnungs- oder Regelungsprozess ist das besonders wichtig.

4. Normalisierte Nachricht

Das Gateway überführt den Feldwert in ein einheitliches Datenmodell. Zum Beispiel:

{
  "site_id": "site-etyek-01",
  "asset_id": "compressor-03",
  "measurement": "active_power",
  "value": 23.871,
  "unit": "kW",
  "measured_at": "2026-09-14T06:32:10Z",
  "quality": "good"
}

Ab diesem Punkt muss die zentrale Verarbeitung die herstellerspezifische Registerzuordnung der einzelnen Zähler nicht mehr kennen. Die Unterschiede auf Feldebene übernehmen das Gateway und das Geräteprofil, während die Plattform mit einheitlichen Begriffen arbeitet.

5. Sichere Übertragung und Pufferung

Die Nachricht gelangt über eine kontrollierte Verbindung zum verarbeitenden System. Bei der Planung der Kommunikation sind Authentifizierung, Verschlüsselung, Berechtigungen, Topic- oder Endpunktstruktur, erneute Zustellung und Fehlerbehandlung festzulegen.

Bricht die Verbindung ab, kann das Gateway die Daten lokal speichern und später mit dem ursprünglichen Messzeitpunkt weiterleiten. Das zentrale System muss mit verspätet und gegebenenfalls mehrfach eintreffenden Nachrichten umgehen können.

Das ist keine spektakuläre Funktion. Ohne sie aber hat die Kurve Lücken, die Abrechnung ist angreifbar, und das Modell lernt aus fehlerhaften Daten.

6. Speicherung und geschäftlicher Bezug

Die Messung von 23,871 kW wird in einem Zeitreihenspeicher abgelegt. Parallel dazu ist aus den Stammdaten der Plattform zu compressor-03 bekannt,

• an welchem Standort er sich befindet;
• zu welcher Produktionslinie er gehört;
• welche Kostenstelle er belastet;
• wer für seinen Betrieb verantwortlich ist;
• welche Nennleistung er hat;
• wann er zuletzt gewartet wurde;
• welcher Vertrag oder welches Projekt ihn betrifft.

Erst jetzt wird der Messpunkt Teil des betrieblichen Geschehens im Unternehmen.

7. Die Zahl interpretieren

Angenommen, der Kompressor läuft gerade im Leerlauf. Laut historischen Daten ist in diesem Zustand eine Leistung von 12–15 kW üblich. Die 23,871 kW sind also nicht deshalb interessant, weil sie für sich genommen eine große Zahl wären, sondern weil sie für diesen Betriebszustand eine deutliche Abweichung darstellen.

Die Regel oder das Modell zur Anomalieerkennung kann Folgendes berücksichtigen:

• den Betriebszustand;
• die Baseline des vorangegangenen Zeitraums;
• die Außentemperatur;
• den Druckwert;
• die Dauer der Abweichung;
• das Qualitätskennzeichen des Sensors.

Ein Ereignis entsteht beispielsweise nur dann, wenn die Leerlaufleistung mindestens 20 Minuten lang über 20 kW bleibt. So löst eine kurzzeitige Spitze keinen unnötigen Alarm aus.

8. Vom Ereignis zur Aufgabe

Das System legt das Ereignis an:

Typ:            hohe Energieaufnahme im Leerlauf
Anlage:         Kompressor 3
Priorität:      mittel
Verantwortlich: Instandhaltung am Standort
Frist:          24 Stunden
Nachweis:       Trend, Betriebszustand, zugehörige Messungen

Aus dem Ereignis kann automatisch ein Arbeitsauftrag entstehen. Der Instandhalter sieht vor Ort die Daten der Anlage, ihre Historie und die Kurve, die die Meldung belegt. Bei der Prüfung hält er fest, dass die Anlage wegen eines schlecht schließenden Ventils auch im unbelasteten Zustand unnötig gearbeitet hat.

9. Maßnahme und Nachkontrolle

Nach der Reparatur des Ventils schließt das System die Aufgabe nicht einfach ab. Es vergleicht den neuen Leerlaufverbrauch mit dem früheren Zustand.

Angenommen, der Wert sinkt wieder auf 13,5 kW. Die Differenz beträgt rund 10,4 kW, solange die Maschine im Leerlauf läuft.

Bei 120 solcher Betriebsstunden pro Monat ergibt sich folgende geschätzte Einsparung:

10,4 kW × 120 h = 1.248 kWh/Monat

Mit den aktuellen internen oder Beschaffungskosten für Energie lässt sich daraus eine finanzielle Auswirkung ableiten. Das System dokumentiert somit nicht nur, dass „wir das Ventil repariert haben“, sondern auch, welches Energie- und Kostenergebnis die Maßnahme gebracht hat.

10. Managemententscheidung

Aus einem einzelnen Fall wird nicht unbedingt eine Strategie. Verarbeitet dieselbe Plattform jedoch ähnliche Ereignisse mehrerer Standorte und Anlagen, erhält das Management Antworten auf Fragen wie:

• welcher Anlagentyp die größten Verluste verursacht;
• wo sich eine messtechnische Zustandsüberwachung am schnellsten amortisiert;
• welcher Standort am schnellsten reagiert;
• wie viel nachgewiesene Einsparung die Maßnahmen gebracht haben;
• welche Anlagen modernisiert oder ersetzt werden sollten;
• welches Pilotprojekt sich unternehmensweit ausrollen lässt.

Die Führungskraft sieht nicht mehr das Register 40001. Sie sieht, welche Kosten ein messbares technisches Problem verursacht hat, wie es behandelt wurde, wie lange es bis zum Abschluss gedauert hat und welches Ergebnis erzielt wurde.

Quellen

• Modbus Organization – Technical Resources
• OASIS MQTT Version 5.0
• NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security
• OrigSmart – webbasiertes Betriebssystem für Unternehmen