TIAN Industrial Automation
EN
All articles

Auf dem Papier ist es eine Eins-zu-eins-Umstellung. Ist sie nie.

Die Migration eines Mitsubishi-FX-Kontaktplanprogramms aus den 1990ern in ABB-800xA-Funktionsbausteine wird als gleichwertiger Austausch verkauft. Ist sie nie. Drei Stellen, an denen die 1:1 bei solchen Aufträgen still bricht, und wie ich sie durcharbeite.

Migrationen wie diese werden als Eins-zu-eins-Umstellung verkauft. Nimm das alte System, bilde nach, was es tut, in neuer Hardware und Software, und gib es so zurück, dass es sich exakt gleich verhält. Sauberer Leistungsumfang, leicht zu verkaufen — auf dem Deckblatt liest es sich wie ein Copy-and-paste mit angehängtem Budget.

Es gibt eine bestimmte Art von Teilsystem, die dieses Deckblatt still widerlegt, und hat man einmal mit einer gerungen, sieht man sie überall: eine alte SPS der Mitsubishi-FX-Serie, ein Programm, das in den 1990ern in Kontaktplan geschrieben wurde, in GX Developer — der älteren Generation von Mitsubishis MELSEC-Programmiersoftware. Die Aufgabe ist, es in ein ABB 800xA zu überführen, neu aufgebaut als Steuerungsmodul und in Funktionsbausteinsprache statt in Kontaktplan codiert. „Gleiches Verhalten, neue Plattform.“ So lautet die Anweisung. Und hier endet die Anweisung.

Zwei Schaltschränke nebeneinander: links ein gealterter Schrank mit einer Mitsubishi-FX-SPS aus den 1990ern, rechts ein neuer Schrank mit einer ABB-800xA-Steuerung und einem I/O-Rack

„Eins zu eins“ ist ein Verkaufssatz, kein Ingenieurssatz

Ich glaube nicht, dass jemand lügt, wenn er es 1:1 nennt. Aus Sicht des Kunden stimmt es: dieselben Knöpfe, dieselbe Abfolge, dieselbe Ausgabe, die Linie läuft wie eh und je. Das ist das Ergebnis, für das er bezahlt, und es ist eine faire Beschreibung.

Aber gleiches Ergebnis und gleiche Logik sind zwei verschiedene Aufgaben, und die Lücke zwischen ihnen ist genau dort, wo sich die meiste Arbeit versteckt. Drei Dinge in einem Teilsystem wie diesem reißen diese Lücke auf. Keines davon steht auf dem Deckblatt.

Eins: Kontaktplan und FUP denken nicht gleich

Kontaktplan und FUP sind nicht zwei Dialekte einer Sprache. Sie sind zwei verschiedene Arten, sich eine Maschine vorzustellen. Kontaktplan liest sich wie Strompfade aus Kontakten und Spulen, mit Strom, der von links nach rechts fließt — ein Denkmodell, das Sinn ergab, als es noch buchstäbliche Relaisschränke beschrieb. FUP liest sich wie Signale, die durch Bausteine fließen. Verschiedene Generationen, verschiedene Instinkte.

Das eine ins andere zu übersetzen ist also nicht mechanisch, in keiner Richtung. Ein Muster, das im Kontaktplan ein offensichtlicher Strompfad ist, kann in FUP zu einem unhandlichen Geflecht aus Bausteinen werden, und etwas, das in FUP sauber ist, wäre rückwärts ein Durcheinander aus Strompfaden. Die Falle ist, dass man die Ausgabe meist zur Deckung bringt, während die darunterliegende Struktur am Ende mit dem Original nichts mehr gemein hat — was sich wie Erfolg anfühlt, bis sich genau ein Sonderfall anders verhält. Das exakte Verhalten zu reproduzieren ist der wirklich harte Teil. Nicht, weil die neue Plattform es nicht könnte, sondern weil zu beweisen, dass sich die neue Version identisch verhält, bedeutet, die alte weit tiefer zu verstehen, als sie nur von oben nach unten zu lesen.

Zwei: die Teile ohne Entsprechung

Manches, worauf sich diese alten Programme stützen, hat in 800xA schlicht keinen Zwilling. Es lässt sich nicht übersetzen; es muss von Hand neu aufgebaut werden, und jedes Einzelne findet man nur durch sorgfältiges Lesen.

  • Sprungbefehle. Der Kontaktplan nutzt bedingte Sprünge (CJ), um ganze Logikabschnitte zu überspringen — und alles, was in einem übersprungenen Abschnitt steckt, hält seinen letzten Zustand, statt zurückgesetzt zu werden, einschließlich Timer, die einfrieren statt zu löschen. Es gibt keinen gleichwertigen Sprung, den man in das FUP hineinlegen könnte, also muss dieser Steuerungsfluss als Ausführungsreihenfolge und Freigabebedingungen neu ausgedrückt werden — ein anderes Denkmodell, kein getauschter Befehl. Reproduziere das Einfrieren-statt-Zurücksetzen, sonst hast du einen stillen Sonderfall-Unterschied eingebaut.
  • Physische Einstellungen, in die Logik verdrahtet. Nicht jeder Sollwert lebt im Code. Manche Werte — etwa Timer-Voreinstellungen — wurden an der realen Maschine über physische Potentiometer eingestellt. Bei der FX halten diese Potis den Wert nicht direkt: Sie landen in speziellen Datenregistern (D8030/D8031), und das Programm skaliert daraus eine Voreinstellung. In der neuen Welt werden daraus Parameter im Steuerungsmodul, was eine Entscheidung erzwingt, die das Original nie aufgeschrieben hat: Was sollte vor Ort einstellbar bleiben, und was war einfach nur, wie man es 1995 gemacht hat?
  • Spezielle Hilfsrelais. Diese Programme stützen sich auf System-Merker der M8000-Reihe — zum Beispiel M8028, der die Zeitbasis bei einer Gruppe von Timern umschaltet —, um Teile der Logik zu formen. Das sind plattformspezifische Systembits. 800xA hat eigene Mechanismen, also muss jede Verwendung dahingehend verstanden werden, was sie tatsächlich tat, und dann mit dem neu erstellt werden, was die neue Plattform bietet — niemals einfach hinüberkopiert.

Drei: das Integrationsmodell, das sich in der „1:1“ versteckt

Das ist die, die man nicht sieht, bis man danach sucht — und ein „gleichwertiges“ Briefing ist das denkbar ungeeignetste Dokument, um sie zu erwischen.

Eine Steuerung arbeitet nie allein. Sie spricht mit allem, was um sie herum sitzt — anderen Steuerungen, I/O, der übrigen Linie — und wie sie spricht, ist Teil dessen, was sie tut, auch wenn nichts davon auftaucht, wenn man das Programm von oben nach unten liest. Die stille Annahme, die in einem 1:1-Briefing steckt, ist, dass diese Unterhaltung unangetastet mitwandert. Oft tut sie das nicht. Wechsle von einer jahrzehntealten Plattform auf eine moderne, und das Integrationsmodell selbst kann sich ändern: wie diese Ecke des Systems mit allem anderen verbunden ist und woraus diese Verbindung überhaupt besteht.

Lass das einen Moment sacken. Gleiche Funktion in der Halle, ein anderes Nervensystem dahinter. Du kannst eine Verbindung, die es in dieser Form nicht mehr gibt, nicht nachbilden — du musst neu konstruieren, wie das Ding mit dem Rest des Systems kommuniziert, und das ist echte Arbeit, die das Deckblatt nie eingepreist hat. Sie ist nichts Exotisches. Sie ist nur aus dem Programmlisting heraus unsichtbar — was genau der Grund ist, warum ein Briefing, das aus diesem Listing heraus geschrieben wurde, sie immer wieder übersieht.

Wie ich ein Programm lese, das vor meiner Geburt geschrieben wurde

Ich bin früh genug in diesem Beruf, dass ein Kontaktplanprogramm aus den 1990ern mir wirklich fremd ist — ich bin 21, etwa achtzehn Monate dabei. Code wie diesen würde ich nie mit Erfahrung schlagen. Also stütze ich mich bewusst auf die Werkzeuge — und ich sage auch, wie, denn die Methode ist die halbe Geschichte.

Der Trick ist, das alte Programm aus seiner nativen Umgebung herauszuholen und in eine schlichte, lesbare Form zu bringen — als PDF exportieren, oder in jedes Format, das erhält, was die Logik tatsächlich tut — und dann ein KI-Modell als Lesehilfe zu nutzen (achte darauf, auf einer unternehmenseigenen, lokal betriebenen On-Prem-ML-Plattform zu arbeiten — und erst, nachdem du sichergestellt hast, dass es mit deinem Unternehmen, dem Kunden und allen anderen, deren Daten betroffen sind, abgeklärt ist): erkläre dies Abschnitt für Abschnitt, mit kommentierten Ausschnitten, die ich direkt gegen die Strompfade prüfen kann. Das verwandelt ein Programm, das jahrzehntelang niemand angefasst hat, in eine lesbare Karte. Von dort aus arbeitest du heraus, welche Teile den Umzug nicht überleben — die Sprünge, die Spezialfälle, die vor Ort eingestellten Voreinstellungen — und denkst durch, wie ein bestimmter Kontaktplanblock als FUP neu aufgebaut werden sollte.

Ich will ehrlich sein über die Grenzen, denn ein Automatisierungspublikum wird dem zu Recht misstrauen. Die KI liegt manchmal falsch. Sie rät die Absicht, gelegentlich mit einer Sicherheit, die sie sich nicht verdient hat. Sie ist eine Lesehilfe und ein Denkpartner, keine Autorität — jede Schlussfolgerung wird gegen das reale Programm und das reale Verhalten geprüft, bevor sie auch nur in die Nähe des neuen Codes kommt. Aber als Weg, ein undurchsichtiges Artefakt aus den 1990ern in etwas zu verwandeln, über das man in Tagen statt Wochen nachdenken kann, verdient sie sich ihren Platz. Das ist genau die einfache Arbeit, in der die Werkzeuge gut sind: nicht die Ingenieursentscheidung treffen, nur das Gestrüpp wegräumen, damit man es kann.

Derselbe Trick, auf die Antwort gerichtet

Das alte Programm zu lesen ist nur die Hälfte. Die andere Hälfte ist, zu beweisen, dass das neue passt — und derselbe Ansatz funktioniert auch dort. Exportiere beide Programme in Text, der ihre Logik spiegelt — den Kontaktplan und das FUP jeweils als PDF abgelegt, oder in jedes Format, das erhält, was der Code tatsächlich tut — und füttere beide gleichzeitig in eine KI, mit der Bitte, sie logisch und funktional zu vergleichen und zu melden, wo sie auseinanderlaufen. Sie baut nichts für dich neu, aber sie ist ein schneller, unermüdlicher zweiter Leser: den Strompfad, der den Umzug nicht überlebt hat, den Sonderfall, den das FUP anders behandelt, die Ausgabe, die sich still verändert hat — sie markiert sie, damit du ihnen nachgehst. Gleiche Einschränkung wie zuvor: Jede Markierung wird gegen das reale Verhalten geprüft, bevor du ihr traust. Aber die Werkzeuge auf beide Seiten zugleich zu richten, verwandelt „Stimmt das überein?“ aus einer Woche manuellen Querlesens in etwas, an dem man an einem Nachmittag iterieren kann.

Das Fazit

Eine Eins-zu-eins-Migration ist real vom Stuhl des Kunden aus und eine Fiktion vom Stuhl des Ingenieurs aus, und beides kann zugleich wahr sein. Die Gefahr ist nicht das Etikett — sie ist es, wenn die Leute, die die Arbeit kalkulieren, daran glauben.

Also: Das lehrt ein Auftrag wie dieser, und das lohnt sich beim nächsten, bevor man auch nur einen einzigen Strompfad anrührt: Wenn etwas als eins zu eins verkauft wird, geh auf die Jagd nach den drei Stellen, an denen es das nicht sein kann.

  • Die Paradigmenlücke — überall dort, wo Quell- und Zielwerkzeug verschieden denken (Kontaktplan zu FUP), ist das Verhalten schwer zu beweisen, nicht nur zu schreiben.
  • Die Waisen — die plattformspezifischen Teile ohne Entsprechung (Sprünge, System-Merker, vor Ort eingestellte Voreinstellungen), die von Hand neu aufgebaut werden müssen.
  • Das Integrationsmodell — wie das Ding mit allem um sich herum kommuniziert, was ein „gleichwertiges“ Briefing gern als unverändert annimmt, obwohl es das nicht ist.

Finde diese drei früh. Bepreise sie ehrlich. Dann hört „eins zu eins“ auf, eine Lüge zu sein, die du auf halbem Weg entdeckst, und wird zu einem Plan, hinter dem du wirklich stehen kannst. Das Etikett war nie das Problem — der Glaube daran war es.

Subscribe