Wer die Steuerungsprogrammierung standardisieren will, verfolgt im Kern ein wirtschaftliches Ziel: Anlagen sollen sich schneller in Betrieb nehmen, leichter warten und ohne Rückgriff auf einzelne Personen erweitern lassen. In vielen mittelständischen Fertigungsbetrieben ist das Gegenteil der Fall. Über Jahre entstandene Programme folgen unterschiedlichen Stilen, verwenden uneinheitliche Bezeichner und enthalten Sonderlösungen, die nur der ursprüngliche Programmierer versteht. Jede Störung, jede Erweiterung und jeder Lieferantenwechsel wird dadurch teurer als nötig. Die Erfahrung zeigt, dass Standardisierung selten an der Technik scheitert, sondern an fehlender Verbindlichkeit, unklaren Zuständigkeiten und dem Eindruck, sie koste nur Zeit. Dabei lässt sich der Einstieg bewusst klein und risikoarm halten, etwa mit einer kurzen Richtlinie für Neuanlagen. Der Beitrag beschreibt, wie sich Programmierrichtlinien, Bausteinbibliotheken, Versionsverwaltung und Prüfverfahren auf Basis der Norm IEC 61131-3 einführen lassen, welche Zuständigkeiten dafür erforderlich sind und wo die typischen Stolperfallen liegen. Er richtet sich an Geschäftsführer, Betriebsleiter und Verantwortliche für Automatisierung und Instandhaltung.
Titelbild: Foto von Raymond Sime auf Unsplash.
Warum uneinheitliche Steuerungsprogramme teuer werden
Der Aufwand uneinheitlicher Programme zeigt sich selten in der Investition, sondern im Betrieb. Eine Störung muss analysiert werden, bevor sie behoben werden kann, und die Analyse dauert länger, wenn Signale, Betriebsarten und Fehlermeldungen von Anlage zu Anlage anders umgesetzt sind. Instandhalter müssen sich jedes Mal neu einarbeiten.
Hinzu kommt das Wissensrisiko. Wenn nur eine Person weiß, wie eine Anlage programmiert ist, entsteht eine Abhängigkeit, die sich bei Krankheit, Ruhestand oder Wechsel zu einem Betriebsrisiko entwickelt. Standardisierung ist daher auch ein Instrument der Risikovorsorge.
- Längere Störungsbehebung durch unterschiedliche Struktur und Benennung.
- Hoher Einarbeitungsaufwand für neue Mitarbeitende und externe Dienstleister.
- Doppelte Entwicklungsarbeit, weil bewährte Lösungen nicht wiederverwendet werden.
- Fehlende Nachvollziehbarkeit von Änderungen, besonders nach Notfalleingriffen.
- Erschwerter Austausch von Steuerungshardware, weil Programme an Hersteller und Sonderfunktionen gebunden sind.
Grundlagen: Die Norm IEC 61131-3
Die Norm IEC 61131-3 beschreibt die Programmiersprachen für speicherprogrammierbare Steuerungen. Sie legt ein gemeinsames Programmiermodell mit Programmorganisationseinheiten, Datentypen und Variablenkonzepten fest. Damit ist sie die Grundlage für herstellerübergreifende Konzepte, auch wenn die Umsetzung bei einzelnen Herstellern abweicht.
| Sprache | Kürzel | Typischer Einsatz |
|---|---|---|
| Kontaktplan | KOP oder LD | Verknüpfungssteuerungen, Interlocks, einfache Logik |
| Funktionsbausteinsprache | FBS oder FBD | Regelungen, Signalverarbeitung, grafische Verknüpfungen |
| Strukturierter Text | ST | Algorithmen, Berechnungen, Datenverarbeitung |
| Ablaufsprache | AS oder SFC | Schrittketten und Ablaufsteuerungen |
| Anweisungsliste | AWL oder IL | Ältere Programme, in neueren Fassungen der Norm nicht mehr vorgesehen |
Die Norm schreibt nicht vor, wie ein Programm aufzubauen ist. Sie bietet Sprachmittel, die erst durch betriebliche Regeln zu einem Standard werden. Entscheidend ist daher, aus den Möglichkeiten eine verbindliche Auswahl zu treffen, etwa welche Sprache für welchen Zweck verwendet wird.
Schritt 1: Ausgangslage erfassen
Am Anfang steht eine Bestandsaufnahme. Welche Steuerungsfamilien sind im Einsatz, welche Entwicklungsumgebungen werden genutzt, und welche Programme sind dokumentiert? Aus der Aufnahme ergibt sich, wo Standardisierung den größten Nutzen bringt.
| Prüffrage | Beispiel für ein Ergebnis | Folge |
|---|---|---|
| Wie viele Steuerungstypen sind im Einsatz? | Vier Hersteller, sieben Familien | Konsolidierung prüfen |
| Liegen aktuelle Projektstände vor? | Nur bei der Hälfte der Anlagen | Sicherung und Archivierung einführen |
| Gibt es Benennungsregeln? | Teilweise je Lieferant | Gemeinsame Konventionen definieren |
| Wer darf Änderungen vornehmen? | Mehrere Personen ohne Protokoll | Änderungsprozess etablieren |
| Sind Ersatzteile und Lizenzen geklärt? | Lizenzen bei Einzelpersonen | Lizenzverwaltung zentralisieren |
Schritt 2: Programmierrichtlinie festlegen
Die Programmierrichtlinie ist das Kernstück. Sie beschreibt, wie Programme aufgebaut und benannt werden und welche Sprachmittel zulässig sind. Eine gute Richtlinie ist kurz genug, um gelesen zu werden, und konkret genug, um prüfbar zu sein.
Typische Inhalte einer Richtlinie
- Namenskonventionen für Variablen, Bausteine, Datentypen und Schnittstellen.
- Struktur des Projekts mit Trennung von Anlagensteuerung, Funktionsbausteinen und Hardwarezuordnung.
- Festlegung zulässiger Sprachen je Aufgabe, zum Beispiel Strukturierter Text für Berechnungen und Ablaufsprache für Schrittketten.
- Regeln für Kommentare, Dokumentation und Änderungshistorie im Baustein.
- Verbot problematischer Konstrukte wie versteckter Seiteneffekte oder nicht dokumentierter Merker.
- Vorgaben für Betriebsarten, Fehlerbehandlung und Wiederanlauf.
Standardisierte Betriebsarten und Zustände
Ein hoher Nutzen entsteht, wenn alle Anlagen dieselbe Zustandslogik verwenden. Dazu zählen Betriebsarten wie Automatik, Handbetrieb und Einrichtbetrieb sowie definierte Zustände wie Stillstand, Anlauf, Produktion, Störung und Halt. Einheitliche Zustandsmodelle erleichtern die Anbindung an übergeordnete Systeme, etwa zur Erfassung von Stillstandsgründen.
Schritt 3: Bausteinbibliothek aufbauen
Eine Bibliothek geprüfter Funktionsbausteine ist das wirksamste Mittel gegen doppelte Entwicklung. Typische Bausteine kapseln Antriebe, Ventile, Sensoren, Regler, Meldesysteme und Kommunikationsfunktionen. Jeder Baustein besitzt eine definierte Schnittstelle, eine Dokumentation und einen Test.
| Bausteintyp | Kapselt | Nutzen |
|---|---|---|
| Antrieb | Freigaben, Rückmeldungen, Störmeldungen, Betriebsarten | Einheitliche Bedienung |
| Ventil und Zylinder | Stellung, Laufzeitüberwachung, Handbetrieb | Schnellere Störungssuche |
| Analogwert | Skalierung, Grenzwerte, Drahtbruch | Konsistente Messwertbehandlung |
| Meldesystem | Priorität, Quittierung, Zeitstempel | Einheitliches Störungsmanagement |
| Kommunikation | Anbindung an MES, OPC UA oder Datenbank | Wiederverwendbare Schnittstellen |
Die Bibliothek benötigt eine verantwortliche Stelle. Ohne Pflege veralten Bausteine, es entstehen Varianten, und der Nutzen schwindet. Änderungen an einem Baustein werden versioniert und in einer Freigabe dokumentiert, damit Anlagen nicht unkontrolliert aktualisiert werden.
Schritt 4: Versionsverwaltung und Änderungsprozess einführen
Steuerungsprogramme werden in vielen Betrieben als Dateien auf Laptops oder Servern abgelegt. Das reicht nicht aus, sobald mehrere Personen Änderungen vornehmen. Eine Versionsverwaltung hält fest, wer wann was geändert hat, und ermöglicht den Rückgriff auf frühere Stände.
- Zentrale Ablage der Projekte mit Zugriffsrechten und Datensicherung festlegen.
- Versionierung der Projekte mit nachvollziehbaren Änderungsbeschreibungen einführen.
- Unterscheidung zwischen Entwicklungsstand, geprüftem Stand und produktivem Stand treffen.
- Notfalländerungen vor Ort dokumentieren und zeitnah in den zentralen Stand übernehmen.
- Abgleich zwischen laufender Steuerung und archiviertem Projekt regelmäßig durchführen.
Besonders wichtig ist der Umgang mit Änderungen im laufenden Betrieb. Wird eine Störung vor Ort durch eine schnelle Programmanpassung behoben, muss diese Anpassung nachgetragen werden. Andernfalls weichen Archiv und Steuerung voneinander ab, und die nächste Wartung beginnt mit einer Unsicherheit.
Schritt 5: Reviews und Tests etablieren
Standards wirken nur, wenn ihre Einhaltung geprüft wird. Ein Review durch eine zweite Person, vor allem bei sicherheitsrelevanten Anlagen, reduziert Fehler und verbreitet Wissen. Statische Prüfwerkzeuge mancher Entwicklungsumgebungen können Namenskonventionen und Strukturregeln automatisch kontrollieren.
- Reviews werden anhand einer kurzen Checkliste durchgeführt, nicht als freie Durchsicht.
- Tests von Bausteinen erfolgen in Simulation oder an Testständen, bevor sie in Anlagen eingesetzt werden.
- Abnahmekriterien für neue Programme enthalten die Einhaltung der Richtlinie.
- Abweichungen werden begründet und dokumentiert, statt stillschweigend akzeptiert.
Zusammenspiel mit Sicherheitstechnik und Normen
Sicherheitsfunktionen unterliegen eigenen Anforderungen. Sicherheitssteuerungen und sicherheitsgerichtete Funktionen werden nach den einschlägigen Normen entwickelt und validiert, und ihre Änderung erfordert besondere Sorgfalt. Standardisierung gilt hier nicht als Erleichterung, sondern als Voraussetzung für Nachvollziehbarkeit und Prüfbarkeit.
Ebenso zu beachten sind Anforderungen der IT-Sicherheit. Steuerungen sind vernetzt und müssen durch Zugriffsschutz, Passwortregeln und Netzwerksegmentierung gesichert werden. Projektstände mit Zugangsdaten gehören nicht auf ungesicherte Datenträger. Der Umgang mit Fernwartung und Herstellerzugängen sollte in der Richtlinie geregelt sein.
Dokumentation und Übergabe von Steuerungsprojekten
Ein Steuerungsprogramm ist erst dann wartbar, wenn die zugehörige Dokumentation vollständig und auffindbar ist. Dazu gehören Funktionsbeschreibung, Signalliste, Betriebsartenkonzept, Netzwerkplan und die Beschreibung der Schnittstellen zu übergeordneten Systemen. Eine einheitliche Dokumentationsstruktur beschleunigt die Einarbeitung und erleichtert Abnahmen.
| Dokument | Inhalt | Zeitpunkt der Übergabe |
|---|---|---|
| Funktionsbeschreibung | Betriebsarten, Abläufe, Störungsverhalten | Vor der Inbetriebnahme |
| Signal- und Adressliste | Ein- und Ausgänge, Bezeichner, Zuordnung zur Hardware | Vor der Inbetriebnahme |
| Projektstand | Vollständiges, lauffähiges Steuerungsprojekt mit Versionsstand | Bei Abnahme |
| Netzwerk- und Zugriffsdokumentation | Adressen, Segmente, Benutzerrechte | Bei Abnahme |
| Bedienungs- und Wartungshinweise | Hinweise für Instandhaltung und Störungsbehebung | Bei Abnahme |
Wird die Übergabe vollständiger Projektstände vertraglich verlangt, lassen sich Abhängigkeiten von einzelnen Dienstleistern deutlich reduzieren. Besonders wichtig ist, dass auch Bibliotheken in der genutzten Version mit übergeben werden, weil Projekte sonst nicht mehr geöffnet oder übersetzt werden können.
Einführung in Stufen: Ein realistischer Zeitplan
Die Einführung gelingt am besten schrittweise. Ein Betrieb sollte nicht versuchen, alle bestehenden Anlagen sofort umzustellen, sondern bei Neuanlagen und größeren Umbauten beginnen. Bestehende Anlagen werden im Zuge ohnehin anstehender Arbeiten angepasst.
| Phase | Inhalt | Typische Dauer |
|---|---|---|
| Vorbereitung | Bestandsaufnahme, Zielbild, Zuständigkeiten | Ein bis zwei Monate |
| Grundlagen | Richtlinie, zentrale Ablage, Versionsverwaltung | Zwei bis drei Monate |
| Pilot | Anwendung bei einer Neuanlage, Auswertung der Erfahrungen | Drei bis sechs Monate |
| Ausbau | Bibliothek erweitern, Lieferantenverträge anpassen | Laufend |
| Verstetigung | Reviews, jährliche Bewertung, Schulung | Laufend |
Schulung und Akzeptanz
Standards werden nur angewendet, wenn die Beteiligten ihren Nutzen verstehen. Kurze Schulungen für Programmierer, Instandhalter und Inbetriebnehmer zeigen, wie Richtlinie und Bibliothek in der Praxis verwendet werden. Rückmeldungen aus der Instandhaltung sollten gezielt eingeholt und in Anpassungen übernommen werden.
Auch die Verbindlichkeit der Geschäftsführung ist ein Erfolgsfaktor. Wenn Ausnahmen regelmäßig geduldet werden, verliert die Richtlinie ihre Wirkung. Ein klarer Ausnahmeprozess mit Begründung und Freigabe verhindert diese Erosion.
Wirtschaftlichkeit: Eine Beispielrechnung
Die folgende Rechnung ist ein reines Beispiel mit angenommenen Werten. Ein Betrieb betreibt zwanzig Anlagen und nimmt jährlich fünf Erweiterungen und Umbauten vor. Angenommen wird, dass die Standardisierung den Engineering-Aufwand je Projekt und die Störungsanalysezeit senkt.
| Position | Annahme | Wert |
|---|---|---|
| Engineering-Aufwand je Projekt vorher | 120 Stunden | 600 Stunden jährlich |
| Reduktion durch Bibliothek und Richtlinie | Angenommen 25 Prozent | 150 Stunden eingespart |
| Stundensatz intern und extern gemischt | Angenommen | 90 Euro |
| Jährliche Einsparung Engineering | 150 Stunden mal 90 Euro | 13.500 Euro |
| Störungsanalyse | Angenommen 40 Stunden Ersparnis im Jahr | 3.600 Euro |
| Gesamte jährliche Einsparung | 13.500 Euro plus 3.600 Euro | 17.100 Euro |
Dem stehen einmalige Aufwände für Richtlinie, Bibliothek und Werkzeuge sowie laufende Pflegekosten gegenüber. Wenn diese einmalig bei etwa 45.000 Euro und jährlich bei 6.000 Euro liegen, ergibt sich rechnerisch ein jährlicher Nettonutzen von 11.100 Euro und eine Amortisation nach rund vier Jahren. Der Beitrag ersetzt keine Prüfung des eigenen Betriebs, zeigt aber, dass sich der Nutzen aus Engineering und Stillstandsvermeidung zusammensetzt.
Praxisbeispiel: Lohnfertiger mit heterogenem Anlagenpark
Ein Lohnfertiger mit rund 150 Beschäftigten betreibt Bearbeitungszentren, Handhabungsroboter und Montageanlagen von acht Lieferanten. Die Steuerungen stammen von drei Herstellern, die Programme von mehreren Integratoren. Bei Störungen verbringen Instandhalter viel Zeit mit der Suche nach Signalen, weil jede Anlage eigene Bezeichner nutzt.
Der Betrieb beschließt, Richtlinie und Bibliothek zunächst nur für Neuanlagen und größere Umbauten zu verlangen. Lieferanten erhalten die Richtlinie als Teil der Bestellung, die Einhaltung wird bei der Abnahme geprüft. Parallel wird ein zentrales Projektarchiv eingeführt, in das alle vorhandenen Stände eingepflegt werden. Nach zwei Jahren ist ein wachsender Teil der Anlagen einheitlich aufgebaut, und die Zeit für die Störungsanalyse sinkt spürbar.
Rollen und Zuständigkeiten
| Rolle | Aufgabe | Hinweis |
|---|---|---|
| Geschäftsführung | Priorisierung, Budget, Verbindlichkeit der Richtlinie | Sponsor des Vorhabens |
| Leitung Automatisierung | Richtlinie, Bibliothek, Reviews | Fachliche Verantwortung |
| Instandhaltung | Anforderungen aus dem Betrieb, Rückmeldung zu Störungen | Wichtige Praxisperspektive |
| Einkauf | Aufnahme der Richtlinie in Lieferantenverträge | Durchsetzung bei Neuanlagen |
| IT und OT-Sicherheit | Zugriffsschutz, Netzwerksegmentierung, Archivierung | Schutz von Projektständen |
| Lieferanten und Integratoren | Umsetzung der Richtlinie, Übergabe vollständiger Projekte | Vertraglich verankern |
Standardisierung nimmt der Programmierung nicht die Kreativität. Sie verlagert die Kreativität dorthin, wo sie gebraucht wird: in die Lösung der Aufgabe statt in die Erfindung neuer Namen.
Häufige Fehler und Stolperfallen
- Richtlinie zu umfangreich: Ein Dokument mit hundert Seiten wird nicht gelesen und nicht geprüft.
- Keine Durchsetzung bei Lieferanten: Die Richtlinie liegt vor, wird aber in Bestellungen nicht verlangt.
- Bibliothek ohne Verantwortliche: Bausteine veralten, und es entstehen parallele Varianten.
- Unkontrollierte Updates: Änderungen an Bibliotheksbausteinen werden in laufende Anlagen übernommen, ohne Test und Freigabe.
- Archiv und Steuerung weichen ab: Notfalländerungen werden nicht nachgetragen.
- Gleichmacherei: Besondere Anforderungen einzelner Prozesse werden ignoriert, statt als begründete Abweichung geregelt.
Quellen und weiterführende Informationen
Die Organisation PLCopen veröffentlicht Informationen und Richtlinien rund um die Programmiersprachen der Norm: PLCopen, Organisation für Steuerungsprogrammierung. Die Norm IEC 61131-3 selbst ist kostenpflichtig über nationale Normenorganisationen erhältlich. Für sicherheitsgerichtete Funktionen sind zusätzlich die jeweils einschlägigen Sicherheitsnormen heranzuziehen.
Checkliste für die Einführung
- Bestandsaufnahme der Steuerungen, Entwicklungsumgebungen und Projektstände durchführen.
- Verantwortliche Stelle für Standardisierung benennen.
- Programmierrichtlinie mit Namenskonventionen, Struktur und Sprachauswahl erstellen.
- Einheitliches Zustands- und Betriebsartenmodell festlegen.
- Bausteinbibliothek mit Dokumentation und Tests aufbauen.
- Zentrale Versionsverwaltung mit Zugriffsrechten und Datensicherung einführen.
- Änderungsprozess für Notfalleingriffe festlegen.
- Review-Checkliste und Abnahmekriterien definieren.
- Richtlinie in Bestellungen und Lieferantenverträge aufnehmen.
- Wirksamkeit anhand von Störungsdauer und Engineering-Aufwand jährlich bewerten.
FAQ
Was bedeutet es, die Steuerungsprogrammierung zu standardisieren?
Gemeint sind verbindliche Regeln für Aufbau, Benennung, Sprachauswahl und Dokumentation von Steuerungsprogrammen, ergänzt durch eine Bibliothek wiederverwendbarer Bausteine und eine Versionsverwaltung. Ziel sind kürzere Inbetriebnahmen und eine leichtere Wartung.
Brauche ich dafür die Norm IEC 61131-3?
Die Norm bildet die Grundlage der gängigen Programmiersprachen und des Programmiermodells. Sie schreibt aber keine betriebliche Richtlinie vor. Der Standard entsteht erst durch die Regeln, die ein Unternehmen auf Basis der Norm festlegt.
Lohnt sich Standardisierung auch bei Steuerungen mehrerer Hersteller?
Ja, auch wenn die Umsetzung aufwendiger ist. Namenskonventionen, Betriebsartenmodelle und Dokumentationsregeln lassen sich herstellerübergreifend festlegen, während Bibliotheken meist je Plattform gepflegt werden.
Wie lassen sich Lieferanten und Integratoren einbinden?
Die Richtlinie wird Bestandteil der Bestellung und der Abnahmekriterien. Zusätzlich sollten vollständige Projektstände einschließlich Dokumentation übergeben und im zentralen Archiv abgelegt werden.
Womit beginnt man am besten?
Mit einer Bestandsaufnahme und einer kurzen Richtlinie für Neuanlagen. Parallel wird ein zentrales Projektarchiv eingeführt. Bibliothek und Reviews wachsen anschließend schrittweise.
