Refaktorisierung einer alten Industrieanwendung – wann ist sie sinnvoll und wie lässt sie sich ohne Risiko für die Produktion umsetzen?

Warum dieses Thema heute relevant ist

Die Refaktorisierung einer alten Industrieanwendung ist längst keine Frage der Code-Ästhetik oder des Wartungskomforts mehr. Heute ist sie eine Entscheidung über die Kontinuität der Produktion, die Planbarkeit der Kosten und den Verantwortungsumfang auf Seiten des Systembetreibers. In vielen Betrieben wurden Steuerungsanwendungen, Bedienwerkzeuge und Kommunikationsebenen über Jahre hinweg ohne einheitliche Architektur weiterentwickelt – oft rund um Geräte, Bibliotheken und Integrationsmechanismen, deren Support eingeschränkt ist oder bereits ausgelaufen ist. Ein solcher Zustand kann eine Zeit lang akzeptabel sein, aber nur so lange, bis jede weitere Änderung mehr kostet als die Funktionalität selbst, die sie bereitstellen soll. Dann lautet die Frage nicht mehr, ob man die alte Anwendung anfassen sollte, sondern ob die Organisation ihr Verhalten unter Produktionsbedingungen noch beherrscht.

Die Relevanz des Themas ergibt sich daraus, dass technische Schulden in industriellen Systemen sehr schnell zu operativen Schulden werden. Wenn eine Anwendung schwer reproduzierbar ist, von einzelnen Personen abhängt, keine belastbaren Regressionstests hat oder ihre Logik Produktionsfunktionen mit Sicherheits- und Diagnosefunktionen vermischt, dann wird jeder Vorfall teurer als ein vergleichbares Problem in einem Bürosystem. Die Folge ist nicht nur ein Stillstand. Hinzu kommen der Aufwand der Instandhaltung, das Risiko fehlerhafter Behelfslösungen unter Zeitdruck, Probleme beim Nachweis der gebotenen Sorgfalt nach einer Änderung sowie die Schwierigkeit, zu trennen, was bereits ein früherer Mangel war und was eine Folge des Eingriffs des Projektteams ist. Für Manager und Product Owner ist das praktische Kriterium einfach: Wenn Zeitaufwand und Unsicherheit bei der Umsetzung weiterer kleiner Änderungen schneller wachsen als ihr geschäftlicher Nutzen, hat die Anwendung einen Zustand erreicht, in dem die Entscheidung zur Refaktorisierung bewusst getroffen werden muss – und nicht erst bis zum ersten kritischen Ausfall aufgeschoben werden darf.

Die meisten Fehler entstehen dann, wenn Refaktorisierung als Modernisierung „ohne Einfluss auf den Prozess“ behandelt wird, obwohl sie tatsächlich die Art verändert, wie das System Entscheidungen trifft. In der Praxis genügt dafür schon ein scheinbar kleiner Eingriff: der Austausch einer Kommunikationskomponente, die Umgestaltung des Aufgabenplans, eine Änderung der Logik für die Pufferung von Sensordaten oder die Bereinigung der Startsequenz nach einem Neustart. Auf dem Papier sind das technische Aufräumarbeiten. In der Anlage können sie jedoch den Zeitpunkt der Signalabgabe, die Reihenfolge der Freigabe von Verriegelungen, die Reaktion bei Kommunikationsverlust oder das Verhalten der Anwendung nach einem Stromausfall verändern. Genau hier geht das Thema Refaktorisierung in die praktische Bewertung von Änderungsrisiken über: Es geht nicht darum, ob der Code „besser“ ist, sondern ob sich Maschine, Linie oder Arbeitsplatz nach der Änderung in Normalzuständen, bei Störungen und nach dem Wiederanlauf weiterhin vorhersehbar verhalten.

Ein guter Test für die Reife der Entscheidung ist die Prüfung, ob das Team die Grenze zwischen einer Änderung der internen Struktur der Anwendung und einer Änderung einer für den Prozess oder die Sicherheit wesentlichen Funktion ziehen kann. Wenn sich diese Grenze nicht auf Ebene von Signalen, Zuständen und Übergangsbedingungen beschreiben lässt, ist das Projekt unabhängig von der Qualität des Auftragnehmers mit Risiko behaftet. In industriellen Umgebungen sind insbesondere Situationen sensibel, in denen die Anwendung an der Start-, Stopp- oder Fehlerquittiersequenz beteiligt ist, Alarme bestätigt oder mit Energieabschaltsystemen und Verriegelungen zusammenarbeitet. An diesem Punkt stellt sich nicht mehr nur die Frage nach der Softwarearchitektur, sondern auch nach dem Schutz vor unerwartetem Anlauf sowie danach, ob die Analyse auch die elektrische Installation, die Steuerungslogik und die Abhängigkeiten zwischen den Geräten umfasst. Genau hier hört eine scheinbar lokale Refaktorisierung auf, eine reine IT-Aufgabe zu sein, und wird zu einer technischen Änderung, die einen vollständigen Entscheidungsprozess erfordert.

Der Bezug zu normativen Anforderungen wird erst an dieser Stelle relevant, denn Normen ersetzen keine Konstruktionsentscheidung, sie strukturieren aber deren Umfang. Wenn eine Änderung die Bedingungen für Anlauf, Stopp, Wiederaufnahme des Betriebs nach einer Störung oder Schutzmaßnahmen beeinflussen kann, muss sie als Risikoveränderung bewertet werden und nicht als gewöhnliche Codepflege. Wenn der Eingriff die Logik betrifft, die mit Energieabschaltung, Verriegelungen oder der Sequenz für einen sicheren Zugang zusammenarbeitet, eröffnet sich damit zwangsläufig auch der Bereich der Anforderungen an den Schutz vor unerwartetem Anlauf. Aus Sicht der Verantwortung ist daher nicht allein die Frage „ob refaktorisiert werden soll“ entscheidend, sondern ob die Organisation nachweisen kann, dass sie die Grenzen der Änderung kennt, Akzeptanzkriterien auf Basis des Prozessverhaltens definiert hat und zwischen einer Systembereinigung und einer Modifikation unterscheiden kann, die eine vollständige Gefährdungsidentifizierung gemäß ISO 12100 sowie die Abstimmung mit der Auslegung der Installation und den Tests an der Anlage erfordert.

Wo Kosten oder Risiken am häufigsten steigen

Der größte Kostenanstieg bei der Refaktorisierung einer alten Industrieanwendung ergibt sich nur selten aus dem Code selbst. Die Ursache liegt meist in einer falschen Einordnung der Änderung: Das Team behandelt sie als Bereinigung der Programmstruktur, obwohl sich tatsächlich das zeitliche Verhalten des Systems, die Reihenfolge der Abläufe oder die Bedingungen für Zustandsübergänge ändern. In einer Produktionsumgebung hat ein solcher Irrtum unmittelbare Auswirkungen auf das Projekt. Der Zeitplan passt nicht mehr zum tatsächlichen Umfang, Tests werden auf IT-Funktionalität statt auf den Prozessablauf ausgelegt, und die Verantwortung für das Ergebnis verteilt sich unscharf zwischen Instandhaltung, Automatisierung und Softwarelieferant. Das praktische Kriterium ist hier einfach: Wenn nach der Änderung die Sequenz für Anlauf, Stopp, Wiederanlauf nach einer Störung oder die Reaktion auf Signale aus Schutzkreisen erneut bestätigt werden muss, handelt es sich organisatorisch nicht mehr um eine „sichere Refaktorisierung“, sondern um eine Änderung, die Risiken für die Produktion verursachen und ein anderes Freigabeverfahren erfordern kann. Schutz vor unerwartetem Anlauf nach ISO 14118 ist in diesem Zusammenhang ein naheliegender Bezugspunkt.

Ein zweiter typischer Bereich, in dem Kosten anwachsen, ist eine Projektentscheidung, die ohne vollständiges Bild der Abhängigkeiten getroffen wird. Alte Industrieanwendungen sind häufig eng mit der Konfiguration der Steuerung, den Aktoren, der Visualisierung, der Datenarchivierung und den Bedienerabläufen verflochten. In der Dokumentation wirkt das wie ein einziges System, in der Praxis sind es jedoch Schichten, die über Jahre von unterschiedlichen Teams weiterentwickelt wurden. Eine Refaktorisierung, die die Lesbarkeit des Codes verbessern oder die weitere Wartung erleichtern soll, kann unbemerkt die Bedeutung von Verzögerungen, Verriegelungsbedingungen, Standardwerten nach einem Neustart oder die Behandlung eines Kommunikationsfehlers verändern. Die Folge ist nicht nur eine technische Korrektur, sondern auch der Aufwand durch Stillstände, zusätzliche Versuche an der Anlage und Streit darüber, ob der Mangel bereits vorher vorhanden war oder erst durch die Änderung entstanden ist. Deshalb sollte vor einer Entscheidung nicht nur der Umfang der Modifikation bewertet werden, sondern auch die Anzahl und Kritikalität der Schnittstellen: Wie viele Signale, Rezepte, Betriebsarten und betriebliche Umgehungslösungen hängen von dem Codeabschnitt ab, der umgebaut werden soll? Je mehr solcher Punkte es gibt, desto weniger sinnvoll ist eine Refaktorisierung „nebenbei“ im Rahmen einer anderen Aufgabe. Das gilt besonders für Projekte der Industrieautomatisierung.

In der Praxis sind vor allem Projekte besonders kostspielig, bei denen das Team die tatsächlichen Anforderungen erst während der Inbetriebnahme erkennt. Ein typisches Beispiel ist der Umbau eines Sequenzmoduls, das laut Beschreibung „dasselbe macht, nur sauberer“. Nach der Implementierung zeigt sich jedoch, dass die vorherige Version nicht dokumentierte Verhaltensweisen enthielt, die Unzulänglichkeiten der Anlage kompensierten: ein kurzes Halten eines Signals, Toleranz gegenüber einem verspäteten Sensor, eine spezifische Reihenfolge beim Quittieren eines Alarms oder eine Bedingung, von der der Zugang für den Service abhängt. Im Code sah das wie ein Fehler oder technische Schuld aus, für den Prozess war es jedoch ein Element der Stabilisierung. Wenn eine Refaktorisierung solche Mechanismen entfernt, ohne ihre Funktion zu erkennen, entstehen die Kosten sofort: Die Zahl der Eingriffe nach der Inbetriebnahme steigt, die Abnahme dauert länger und die Logik muss unter dem Druck des laufenden Betriebs wiederhergestellt werden. Deshalb sollte die Sinnhaftigkeit einer Refaktorisierung auch danach beurteilt werden, ob sich das Verhalten des bestehenden Systems zuverlässig nachbilden lässt. Wenn die Organisation weder über eine Ereignisaufzeichnung noch über belastbare Beschreibungen der Betriebsarten und auf dem realen Prozess basierende Testszenarien verfügt, muss zunächst diese Grundlage geschaffen werden, bevor über einen Umbau entschieden wird.

Dieses Thema geht unmittelbar in die praktische Bewertung von Änderungsrisiken nach ISO 12100 über, wenn die Modifikation Schutzfunktionen, Sequenzen für den sicheren Zugang, die Bewegungssteuerung von Aktoren oder das Verhalten der Anlage nach Spannungsverlust und Spannungsrückkehr beeinflusst. In einem solchen Umfang beschränkt sich der Fehleraufwand nicht auf Programmkorrekturen, denn es stellt sich zusätzlich die Frage der Verantwortung für die Freigabe der Änderung zum Betrieb. Wenn die Anwendung mit hydraulischen oder pneumatischen Systemen oder mit Lösungen wie Zweihandsteuerung zusammenarbeitet, wird die Grenze zwischen Refaktorisierung und technischer Änderung noch schmaler und es muss geprüft werden, ob die Auslegungsannahmen der Schutzmaßnahmen nicht verletzt wurden. Erst an dieser Stelle ist der Rückgriff auf strukturierte Methoden der Risikobeurteilung sachgerecht, einschließlich des in der Praxis auf Grundlage von ISO/TR 14121-2 verwendeten Ansatzes, und bei hydraulischen Systemen auch auf die durch DIN EN ISO 4413 geordneten Konstruktionsanforderungen. Es geht dabei nicht um Formalismus um des Formalismus willen, sondern um eine einfache Entscheidungsregel: Wenn eine Änderung die Sicherheit des Prozesses oder der Bedienung beeinflussen kann, müssen ihre Kosten zusammen mit Validierung, Tests an der Anlage und dem Verantwortungsrahmen kalkuliert werden – nicht ausschließlich anhand der Arbeitszeit des Programmierers.

Wie man das Thema praktisch angeht

In der Praxis wird der Nutzen einer Refaktorisierung einer alten Industrieanwendung nicht nach der technologischen Attraktivität der Änderung beurteilt, sondern danach, ob sich damit zugleich das Betriebsrisiko senken und die Kontrolle über die Umsetzung behalten lässt. Für Manager und Product Owner bedeutet das einen einfachen Perspektivwechsel: Die Frage lautet nicht, ob es sich „lohnt, den Code aufzuräumen“, sondern ob der aktuelle Zustand der Anwendung Wartung, Tests, Fehlerbehebung oder die anforderungskonforme Umsetzung weiterer Änderungen tatsächlich erschwert. Wenn die Antwort ja lautet, ist eine Refaktorisierung sinnvoll – allerdings nur in einem Umfang, der sich vom laufenden Produktionsbetrieb trennen und anhand messbarer Auswirkungen bewerten lässt. Ein gutes Entscheidungskriterium ist hier der Vergleich zweier Kostenarten: der Kosten, die entstehen, wenn die Anwendung im aktuellen Zustand belassen wird – einschließlich Stillständen, Diagnosezeiten, Abhängigkeit von einzelnen Personen und dem Risiko fehlerhafter Änderungen – sowie der Kosten eines kontrollierten Umbaus einschließlich Tests, Validierung und Inbetriebnahme. Ohne einen solchen Vergleich gerät das Projekt in der Regel außer Kontrolle, weil das Team die Bereinigung des Codes aus dem für Funktionalität vorgesehenen Budget finanziert, während die Verantwortung für die Auswirkungen an der Anlage ungeklärt bleibt.

Deshalb sollte die erste Entscheidung nicht „wir schreiben neu“ oder „wir lassen es so“, sondern die Festlegung der Änderungsgrenze sein. In einem reifen Vorgehen trennt man den Teil, der ausschließlich die Struktur der Software betrifft, von dem Teil, der Einfluss auf Prozesslogik, Start- und Stoppsequenzen, Betriebsarten, die Kommunikation mit Antrieben und das Verhalten nach einer Störung der Stromversorgung hat. Diese Unterscheidung wirkt sich unmittelbar auf Kosten und Organisation aus. Eine Änderung, die auf die reine Strukturierung des Codes beschränkt ist, kann in einem kürzeren Zyklus und mit geringerem Einbezug der Instandhaltung umgesetzt werden. Eine Änderung, die in das Verhalten der Maschine oder Linie eingreift, erfordert dagegen bereits einen Testplan an der Anlage, ein Servicefenster, ein Rollback-Verfahren sowie eine eindeutige Festlegung, wer die Freigabe für den Betrieb erteilt. Dabei sollte nicht nur die Dauer der Programmierarbeiten gemessen werden, sondern auch die Zeit zur Wiederherstellung des Systems nach einem fehlgeschlagenen Versuch, die Anzahl der Bereiche, die von Regressionstests erfasst werden, und die Zeit, die nach dem Anlauf für die Diagnose einer Abweichung benötigt wird. Das sind Kennzahlen, die zeigen, ob die Refaktorisierung das Projektrisiko tatsächlich reduziert und nicht nur den Arbeitskomfort des Entwicklungsteams verbessert.

Ein praktisches Beispiel ist typisch für ältere Steuerungsanwendungen: Der Code enthält vielfach duplizierte Abschnitte für Bewegungsfreigaben, Alarmbehandlung und Übergänge zwischen Hand- und Automatikbetrieb. Das Team möchte diese vereinheitlichen, weil die bestehende Struktur die Weiterentwicklung erschwert und zu Abweichungen zwischen den Stationen führt. Eine solche Entscheidung ist erst dann sinnvoll, wenn geprüft wurde, ob die Vereinheitlichung die Bedingungen, unter denen ein Aktor eine Bewegungsfreigabe erhält, nicht verändert und ob nach einem Neustart der Steuerung keine andere Sequenz zur Wiederherstellung des Zustands entsteht. Wenn die Anwendung außerdem Ventile, Antriebe oder Systeme mit gespeicherter Energie steuert, kann selbst eine scheinbar „interne“ Refaktorisierung in den Bereich der Risikobewertung von Änderungen nach ISO 12100 fallen und eine Analyse des Schutzes vor unerwartetem Anlauf nach ISO 14118 erfordern. In einem solchen Fall besteht eine sinnvolle Vorgehensweise darin, die Refaktorisierung schrittweise umzusetzen: zunächst die Reproduktion des Verhaltens in einer Testumgebung, dann die Ausgliederung von Modulen ohne Änderung der Logik und anschließend die Verifikation an der Anlage mit vorbereitetem Rücknahmeszenario. Das begrenzt die operative Verantwortung und ermöglicht es, die Umsetzung zu stoppen, bevor sich ein Problem auf die Produktion auswirkt.

Erst an diesem Punkt ist ein normativer Bezug erforderlich, denn Normen ersetzen keine technische Entscheidung, sie strukturieren jedoch den Moment, in dem eine Änderung nicht mehr ausschließlich Programmierarbeit ist. Wenn die Refaktorisierung Einfluss auf Schutzmaßnahmen, Bedingungen für einen sicheren Zugang, die Energieabschaltung oder das Verhalten von Systemen nach Stillstand und Wiederanlauf hat, fällt sie zwangsläufig in den Bereich einer strukturiert durchgeführten praktischen Änderungsrisikobewertung, auch unter Nutzung eines aus ISO/TR 14121-2 bekannten Ansatzes. Wenn das Risiko eines unerwarteten Anlaufs besteht, muss nicht nur der Code selbst geprüft werden, sondern auch die Logik der Energieabschaltung und Energiewiederkehr, was unmittelbar zu Fragestellungen führt, die mit ISO 14118 verbunden sind. Ist die Anwendung zudem mit Hydraulik oder Pneumatik verknüpft, darf die Bewertung die Auslegungsannahmen dieser Systeme nicht ausblenden, denn eine fehlerhafte Steuersequenz kann deren sicheres Verhalten unabhängig von der Korrektheit des Programms selbst beeinträchtigen; dann ist es auch gerechtfertigt, auf die Sicherheitsanforderungen nach ISO 4413 zurückzugreifen. In der Praxis bedeutet das nur eines: Über den Umfang der Refaktorisierung entscheidet nicht die Eleganz der Lösung, sondern die Grenze der Verantwortung für das sichere Verhalten der Anlage nach der Änderung.

Worauf bei der Umsetzung zu achten ist

Die Umsetzung einer Refaktorisierung einer alten Industrieanwendung ist der Moment, in dem selbst eine richtige Architekturentscheidung zu einem operativen Problem werden kann. Der Sinn des gesamten Vorhabens endet dort, wo die Änderung zwar den Code verbessert, aber die Vorhersehbarkeit des Anlagenverhaltens verschlechtert oder die Verantwortung des Teams über das hinaus erweitert, was erkannt und freigegeben wurde. Der häufigste Fehler besteht darin, die Umsetzung wie ein gewöhnliches Release einer neuen Version zu behandeln. In einer Produktionsumgebung zählt nicht nur, ob die Anwendung funktioniert, sondern auch, ob sich nach der Änderung alle Übergangszustände identisch verhalten: Anlauf nach Stromausfall, Neustart der Kommunikation, Wiederherstellung von Rezepturen, Behandlung von Alarmen, Verriegelungen und Handbetriebsarten. Das praktische Kriterium ist einfach: Wenn das Team nicht eindeutig beschreiben kann, welche Verhaltensweisen nach der Umsetzung unverändert bleiben müssen, dann sind die Voraussetzungen für eine sichere Inbetriebnahme noch nicht gegeben.

In der Phase der Implementierungsentscheidung muss klar zwischen einer technisch reversiblen Änderung und einer Änderung unterschieden werden, die nach der Inbetriebnahme einen neuen Ausgangszustand schafft und die Rückkehr erschwert. Das hat unmittelbare Auswirkungen auf Kosten und Terminplanung. Eine Refaktorisierung, die gleichzeitig Aktualisierungen von Steuerungen, Visualisierung, Datenserver und Schnittstellen zu übergeordneten Systemen erfordert, ist keine einzelne Programmieraufgabe mehr; sie wird zu einer koordinierten Produktionsänderung mit mehreren potenziellen Ausfallpunkten. Deshalb sollte vor der Implementierung ein Freigabekriterium festgelegt werden, das sich nicht auf die Aussage „Tests bestanden“ stützt, sondern auf die Fähigkeit, die Änderung innerhalb eines für den Prozess akzeptablen Zeitfensters kontrolliert zurückzunehmen. Gibt es kein belastbares Rollback-Verfahren, fehlt auch die Grundlage für die Behauptung, das Risiko sei beherrscht. In der Praxis ist es sinnvoll, nicht eine abstrakte „Qualität der Implementierung“ zu messen, sondern Kennzahlen wie die Zeit zur Wiederherstellung der vorherigen Version, die Anzahl der von der Änderung abhängigen Schnittstellen sowie die Zahl der Funktionen, deren Korrektheit sich an der Anlage ohne Eingriff in die Produktion bestätigen lässt.

Ein gutes Beispiel ist eine Situation, in der die Refaktorisierung die Behandlung von Ausnahmen und Fehlermeldungen bereinigt, gleichzeitig aber die Reihenfolge der Initialisierung nach einem Systemneustart verändert. Auf dem Teststand wirkt alles korrekt, weil die Geräte sofort verfügbar sind und der Prozess nicht unter Last läuft. In der Anlage kann derselbe Code jedoch eine Sequenz zu einem anderen Zeitpunkt als bisher starten, was zum Verlust der Synchronisation mit den Antrieben, zu einer fehlerhaften Interpretation von Bereitschaftssignalen oder zum Stillstand einer Materialcharge in einem Zwischenzustand führt. Ein solcher Vorfall muss keine technische Störung im engeren Sinn bedeuten, verursacht aber Kosten durch Stillstand, Ausschuss, erneutes Anfahren und zusätzliche Verantwortung bei der Entscheidung über die Wiederaufnahme des Betriebs. Genau hier geht das Thema Refaktorisierung in die praktische Bewertung von Änderungsrisiken nach ISO 12100 über: nicht dann, wenn die Änderung groß ist, sondern dann, wenn sich ihre Auswirkungen nicht mehr auf die Softwareebene begrenzen lassen.

Die Grenze der Verantwortung wird noch deutlicher dort, wo die Anwendung Schutzfunktionen, die Logik zur Bewegungsfreigabe, Entlastungssequenzen, das Anhalten und den Wiederanlauf nach einer Störung beeinflusst. In einem solchen Fall reicht weder ein Vergleich der Code-Versionen noch ein vom Integrator durchgeführter Funktionstest aus. Erforderlich ist eine strukturierte Bewertung, ob die Änderung das Risikoniveau verändert und ob sie die Annahmen für den sicheren Betrieb der Maschine oder Anlage nicht verletzt. Das ist der natürliche Zeitpunkt für den Einstieg in den Bereich der Gefährdungsidentifizierung gemäß ISO 12100 sowie der in der Bewertung von Änderungsrisiken angewandten Praxis; in komplexeren Fällen kann auch der methodische Ansatz nach ISO/TR 14121-2 hilfreich sein. Wenn die Anwendung hydraulische oder pneumatische Systeme steuert, muss zusätzlich geprüft werden, ob die neue Logik die Bedingungen für die sichere Steuerung von Energie und die Bewegungsreihenfolge verändert; dann sind auch die für diese Systeme geltenden konstruktiven Anforderungen relevant und nicht nur die Korrektheit des Programms selbst. Für das Projektteam bedeutet das vor allem eines: Eine Implementierung kann erst dann als vorbereitet gelten, wenn der Umfang der technischen, betrieblichen und compliancebezogenen Verantwortung vor der Inbetriebnahme benannt wurde und nicht erst nach dem ersten Vorfall.