Protokoll-Reverse-Engineering: Alte Maschinen sprechen wieder.
Das häufigste Problem in Manufacturing & Automation: Die alte Maschine läuft — aber die neue Software kann nicht mit ihr sprechen. Der Hersteller der Steuerung existiert nicht mehr. Protokoll-Dokumentation: keine. Unsere Lösung: Wir lesen das Protokoll selbst.
Warum proprietäre Protokolle existieren
In den 1990ern und 2000ern entwickelte jeder Hersteller sein eigenes Kommunikationsprotokoll — oft als Schutzmaßnahme, um Lock-in zu erzeugen. RS-232, RS-485, CAN-Bus oder proprietäre Ethernet-Erweiterungen waren die Träger. Das Format: bekannt nur dem Hersteller.
Heute, 20–30 Jahre später, ist dieser Hersteller oft verschwunden, übernommen oder hat das Produkt eingestellt. Die Maschine läuft, aber sie ist stumm — sie spricht eine Sprache, die niemand mehr versteht.
Phase 1: Passive Traffic-Analyse
Bevor wir ein einziges Byte senden, hören wir zu. Passives Monitoring bedeutet: Wir klinken uns in die Kommunikationsleitung ein, ohne das Verhalten der Maschine zu beeinflussen.
# Typisches Setup für RS-232 Monitoring
Maschine ──RS-232── [Y-Kabel] ── USB-Serial Adapter ── Capture PC
# Gleichzeitig: Original-Terminal bleibt angeschlossen
Maschine ──RS-232── [Original Terminal] (normaler Betrieb)
Wir erfassen typisch 48–72 Stunden im realen Produktionsbetrieb. Warum so lang? Weil viele Muster nur bei bestimmten Ereignissen auftreten — Schichtwechsel, Werkzeugwechsel, Fehlerzustände, Produktionsstarts.
Phase 2: Musteranalyse & Protokoll-Rekonstruktion
Nach dem Capture beginnt die eigentliche Arbeit. Wir suchen nach:
🔍
Start/End-Sequenzen
Konstante Byte-Folgen die Nachrichten begrenzen. Oft 0xAA 0x55 oder STX/ETX (0x02/0x03).
🔢
Längenfelder
Bytes die die Länge der Nutzlast angeben. Typisch 1–2 Bytes, oft big-endian.
✅
Prüfsummen
CRC8, CRC16, XOR-Checksum oder einfache Summen-Modulo. Identifizierbar durch Korrelation.
📋
Befehlscodes
Wiederkehrende Byte-Werte an fixer Position = Opcode. Korreliert mit beobachtetem Verhalten.
Ein reales Beispiel: CNC-Protokoll dekodieren
Im Fallbeispiel MFG-001 fanden wir nach 3 Tagen Analyse folgendes Frame-Format:
Das Timing war kritisch: Die Steuerung erwartete eine Antwort innerhalb von 50 ms. Überschreitung führte zu einem Timeout-Fehler und Reset der Verbindung. Dieses Timing-Requirement war nur durch dynamische Messung — nicht aus statischer Analyse — zu ermitteln.
Phase 3: Die Custom Protocol Bridge
Mit dem vollständig dokumentierten Protokoll implementieren wir einen Parser in Node.js. Wichtige Design-Entscheidungen:
Fehlertoleranz first
Alte Maschinen senden manchmal fehlerhafte Frames (Rauschen auf der Leitung, Timing-Jitter). Der Parser muss resilient sein — er darf nicht abstürzen, sondern muss den Frame verwerfen und weiter scannen.
Vollständiges Logging
Jeder Frame wird geloggt — dekodiert und als Raw-Hex. Bei Problemen im Betrieb lässt sich so genau nachvollziehen, was die Maschine gesendet hat.
Automatischer Reconnect
Alte serielle Verbindungen können instabil sein. Die Bridge muss automatisch reconnecten und den State korrekt zurücksetzen.
Was schief gehen kann — und wie wir es vermeiden
Protokoll-Varianten
Manche Hersteller haben das Protokoll über Software-Versionen verändert. Immer mehrere Firmware-Versionen der Maschine im Capture erfassen.
Undokumentierte Sonderzustände
Fehlercodes, Kalibrierbefehle oder Wartungsmodi sind oft nur in bestimmten Situationen sichtbar. Wartungsprotokoll des Kunden systematisch durcharbeiten.
Timing-Abhängigkeiten
Manchmal ist nicht nur das Protokoll proprietär, sondern auch das Timing. Immer mit Oszilloskop messen, nicht nur mit Software-Capture.
Unterschied Polling vs. Event
Manche Steuerungen senden Daten nur auf Anfrage (Polling), andere push-basiert. Das grundlegende Kommunikationsmodell früh verstehen.
Fazit: Protokoll-RE ist machbar — wenn man systematisch vorgeht
In unserer Erfahrung lassen sich über 90 % der proprietären industriellen Protokolle innerhalb von 1–2 Wochen vollständig dokumentieren. Voraussetzung: systematische Methodik, ausreichend Capture-Zeit und die Bereitschaft, auch Randfälle zu erfassen.
Das Ergebnis: Eine Maschine, die seit 20 Jahren stumm war, spricht plötzlich wieder — mit Ihrer modernen Software, in Echtzeit, zu einem Bruchteil der Kosten einer neuen Anlage.