Eine Funktion muss ergänzt oder korrigiert werden.
Betroffene Zustände, Schnittstellen und Seiteneffekte werden vor der Implementierung eingegrenzt. Die Änderung bleibt so klein und prüfbar wie sinnvoll.
SPS · Automatisierungstechnik
SPS-Programmierung für gewachsene Maschinensteuerungen.
Externe SPS-Programmierung für schwierige Bestandsprojekte: Maschinenlogik verstehen, Änderungen begrenzen, Prüfungen dokumentieren und die reale Maschinenprüfung getrennt vorbereiten.
Bestandsprojekt zuerst verstehen
Gewachsene Maschinenlogik nicht blind neu schreiben.
In einer gewachsenen Maschinensteuerung stecken Abläufe, Verriegelungen, Betriebsarten und Sonderfälle, die nicht vollständig aus Variablennamen oder einem Stromlaufplan hervorgehen.
Deshalb beginnt SPS-Programmierung im Bestand mit Quellstand, Zielhardware, Bibliotheken, Kommunikationswegen und dem beobachtbaren Maschinenverhalten. Erst wenn die betroffene Logik und ihre Nachbarschaft verstanden sind, lege ich den Änderungsumfang fest.
Das ist besonders wichtig, wenn der laufende Stand unklar ist, mehrere Varianten existieren oder bisher nur direkt an der realen Maschine getestet werden konnte.
Aufgaben im Bestand
Wobei ich im Bestand unterstützen kann.
Maschinenlogik ist nur noch im Code vorhanden.
Abläufe, Betriebsarten, Verriegelungen und Datenflüsse werden aus Code, Dokumenten und beobachtbarem Verhalten rekonstruiert und verständlich beschrieben.
Ein bestehendes Team braucht Unterstützung bei einer schwierigen Änderung.
Die Arbeit kann auf Analyse, eine abgegrenzte Funktion, Teststruktur oder Dokumentation fokussiert werden, ohne Rollen und Verantwortlichkeiten unnötig zu verschieben.
Arbeitsfolge
Ändern und prüfen gehören zusammen.
Die genaue Tiefe hängt vom Bestand ab. Die Trennung der Nachweisstufen bleibt jedoch ausdrücklich erhalten.
Quellstand absichern
Projektdateien, Gerät, Runtime, Bibliotheken und der tatsächlich laufende Stand werden soweit möglich abgeglichen. Abweichungen bleiben als offene Punkte sichtbar.
Logik und Grenze verstehen
Zustandsfolgen, Ein-/Ausgänge, Verriegelungen, Datenhaltung und Kommunikation rund um die betroffene Funktion werden erfasst.
Änderung dokumentieren
Ich dokumentiere die Änderung, ihre Begründung, betroffene Schnittstellen und offene Annahmen. Umbauten außerhalb des vereinbarten Umfangs vermeide ich.
Früh prüfen
Build, statische Prüfung, Logiktests oder DryRun werden dort genutzt, wo Engineering-System und konkreter Bestand dies sinnvoll zulassen.
An der realen Maschine prüfen
Inbetriebnahme, reales Ein-/Ausgangsverhalten, Timing und Prozesswirkung werden in einer eigenen Phase unter den Vorgaben des Herstellers oder Betreibers geprüft. Über die Freigabe entscheiden die zuständigen Stellen.
Getrennte Nachweisstufen
Frühe Tests helfen. Sie ersetzen die Maschine nicht.
Jede Stufe beantwortet andere Fragen und wird entsprechend gekennzeichnet.
QuellcodeStruktur, Abhängigkeiten und statische Auffälligkeiten
BuildEngineering-Stand und Bibliotheken reproduzierbar prüfen
Logik / DryRunAbläufe ohne vollständige reale Peripherie untersuchen
Reale MaschineHardware-, Timing-, Sicherheits- und Prozessverhalten prüfen
CODESYS 2.3 und 3.5 bilden einen konkreten Schwerpunkt. Bei anderen SPS-Plattformen wird vorab geprüft, ob Engineering-Umgebung, Hardware und Aufgabe fachlich passen. Es gibt kein Versprechen, jedes System gleich tief abzudecken.
Umfang und Budget werden nach Sichtung des Bestands phasenweise vereinbart.
Analyse, Änderung und reale Maschinenprüfung können getrennt beauftragt und mit den jeweils verantwortlichen Stellen abgestimmt werden.
Fragen und Grenzen
Fragen zur SPS-Programmierung im Bestand
Wann ist ein externer SPS-Programmierer für ein Bestandsprojekt sinnvoll?
Wenn eine Änderung tiefes Verständnis der vorhandenen Maschinenlogik verlangt, interne Kapazität fehlt oder ein festgefahrener Bestand zunächst geordnet werden muss. Der Einstieg kann auf eine klar begrenzte Baugruppe, Funktion oder Fehlerklasse beschränkt werden.
Werden alle SPS-Hersteller und Programmiersysteme unterstützt?
Es gibt kein pauschales Universalversprechen. Der konkrete Steuerungstyp, die Engineering-Umgebung, Hardware, Bibliotheken und verfügbaren Projektstände werden vor einer Zusage geprüft. Ein ausgewiesener Schwerpunkt liegt auf CODESYS 2.3 und 3.5.
Kann SPS-Software ohne reale Maschine vollständig validiert werden?
Nein. Quellcodeanalyse, reproduzierbarer Build, Logiktests oder ein geeigneter DryRun können Risiken früher sichtbar machen. Reales Ein-/Ausgangsverhalten, Timing, Antriebe, Sicherheit und Prozesswirkung müssen getrennt am passenden Prüfstand oder an der Maschine geprüft werden.
Wie werden KI-gestützte Engineering-Werkzeuge eingesetzt?
KI-gestützte Werkzeuge können Analyse, Dokumentation und wiederholbare Prüfschritte beschleunigen. Werkzeuge und Datenwege werden vor dem Quellcodezugriff vereinbart. Ich prüfe Vorschläge und Ergebnisse selbst und übernehme KI-Ausgaben nicht ungeprüft. Über den Produktivbetrieb entscheiden die zuständigen Stellen.
Passende Themen
SPS-Bestand weiter einordnen
CODESYSCODESYS und Legacy-SteuerungenDer konkrete Schwerpunkt für CODESYS 2.3, CODESYS 3.5, Migration und versionierte Quellstände.FACHBEITRAGSPS-Software testenQuellcodeanalyse, Build, Logiktest, DryRun und reale Maschinenprüfung sauber unterscheiden.BESTANDTechnische BestandsanalyseWenn Quellstände, Varianten, Bibliotheken, Updatewege und Dokumentation zunächst inventarisiert werden müssen.
Maschinensteuerung konkret besprechen
Eine Änderung im SPS-Bestand lässt sich nicht sauber eingrenzen?
Nennen Sie Steuerung, Engineering-Version, Maschinentyp, vorhandene Projektstände und die gewünschte Änderung. Danach lässt sich ein erster, prüfbarer Arbeitsumfang festlegen.