Pascal, altes C, Assembler: Wie wir unlesbaren Code modernisieren.
„Der Code ist auf einer Floppy-Disk. Der Entwickler ist seit 10 Jahren in Rente. Die IDE läuft nur auf Windows 98." — Das ist kein Einzelfall. Es ist die Realität in vielen Produktionsbetrieben. Hier ist unsere Methodik, wie wir dennoch ans Ziel kommen.
Das Kernprinzip: Behavior statt Code verstehen
Der häufige Fehler: Man versucht, den Code zu lesen und zu verstehen. Das ist oft unmöglich — proprietäre Compiler, obskure Syntax, fehlende Kontexte. Unser Ansatz: Wir beobachten, was das System tut — nicht wie es das tut.
Das System zeigt sein Verhalten nach außen: in Signalen, Reaktionen, Timing, Zuständen. Diese externe Sicht ist immer zugänglich — unabhängig davon, ob wir den Code haben oder nicht.
Phase 1: Alles sammeln, was verfügbar ist
Quellcode (falls vorhanden)
Auch fragmentarisch wertvoll. Selbst 20–30 % des Codes geben wichtige Hinweise auf Variablennamen, Strukturen, Algorithmen.
Handbücher & Bedienungsanleitungen
Beschreiben Funktionen aus Benutzerperspektive — oft die einzige externe Spezifikation.
Wartungslogbücher
Handschriftlich, oft jahrelang geführt. Enthalten Fehlermuster, Sonderfälle, undokumentierte Verhalten.
Interviews mit Bedienpersonal
Erfahrene Maschinenbediener kennen das Verhalten in- und auswendig. Gold wert.
Elektropläne & Verdrahtungsdiagramme
Zeigen, welche Signale wo ankommen — essentiell für Dynamic Analysis.
Phase 2: Dynamic Analysis — das System beobachten
Mit Oszilloskop und Logic Analyzer klinken wir uns an die relevanten Signalleitungen: digitale I/O, serielle Schnittstellen, Analogsignale. Dann beobachten wir systematisch:
# Systematische Beobachtungsszenarien:
Normal-Betrieb: Alle Signale im Normalbetrieb kartieren
Produktwechsel: Welche Signale ändern sich, in welcher Reihenfolge?
Fehlerzustände: Absichtlich Fehler provozieren, Reaktion aufzeichnen
Schichtwechsel: Initialisierungssequenzen beim Start beobachten
Sicherheitsauslöser: E-Stop, Notaus, Sicherheitsschaltungen
Phase 3: State Machine Rekonstruktion
Aus den Beobachtungen entsteht ein State Diagram. Jeder stabile Zustand des Systems wird benannt und dokumentiert, jeder Übergang (mit seinen Bedingungen) kartiert.
Im Fallbeispiel AUTO-003 (Abfüllanlage, 2001) rekonstruierten wir 12 Betriebszustände und 34 Übergangsbedingungen — darunter 7 Sicherheitsbedingungen, die vollständig undokumentiert, aber aktiv waren. Diese wären ohne Dynamic Analysis verloren gegangen.
⚠️ Die häufigste Falle: Undokumentierte Sicherheitslogik
In jedem Legacy-System, das wir analysiert haben, gab es undokumentierte Sicherheitsbedingungen — eingebaut von einem Entwickler, der ein konkretes Problem gelöst hat, ohne es zu dokumentieren. Diese Logik ist essentiell. Ein Rewrite ohne Dynamic Analysis würde sie verlieren und könnte zu gefährlichen Situationen führen.
Phase 4: Der Rewrite — in moderner Sprache
Mit vollständiger State Machine dokumentiert, schreiben wir den Code neu. Unsere Zielsprachen je nach Kontext:
C++
Embedded-Systeme, Echtzeit-Anforderungen, STM32/ESP32/nRF
Python
PC-basierte Steuerungen, Datenverarbeitung, Scripting-intensive Logik
TypeScript
Web-basierte HMIs, Cloud-Backends, REST APIs
Fazit: Code ist nicht das Hindernis
Kein Quellcode bedeutet nicht, dass eine Modernisierung unmöglich ist. Es bedeutet nur, dass wir anders vorgehen. Behavior-First statt Code-First. Das Ergebnis ist oft besser dokumentiert, strukturierter und wartbarer als der Original-Code — der häufig über Jahrzehnte ohne Plan gewachsen war.