SPS-Coding-Standards: von Namenskonventionen zur Bibliothek

1.Warum Namenskonventionen allein kein Standard sind

Fast jedes Team, das sich zur Standardisierung entschließt, beginnt mit Präfixen. bMotorRun, iCounter, rPressure — an einem Nachmittag vereinbart, in ein einseitiges Dokument geschrieben und über die nächsten zwei Projekte still erodiert.

Der Grund für die Erosion ist nicht Nachlässigkeit. Es ist, dass eine Präfix-Tabelle die kleinste Frage beantwortet, die ein Standard zu beantworten hat. Sie sagt, wie eine Variable heißt. Sie sagt nichts darüber, was ein Funktionsbaustein an seiner Schnittstelle bereitstellen muss, wer einen Bibliotheksbaustein ändern darf, oder was passiert, wenn ein Projekt eine Variante von etwas braucht, das es schon gibt.

Genau diese Fragen entscheiden, ob ein zweiter Ingenieur das Projekt übernehmen kann — und genau sie werden übersprungen, weil sie Entscheidungen verlangen statt Konventionen.

2.Die vier Ebenen eines tragfähigen Standards

2.1.Ebene 1: Namensgebung, die trägt

Datentyp-Präfixe sind das Einstiegsniveau und ihr Geld wert. Die ausführliche Tabelle steht im Artikel zu den SPS-Best-Practices; für einen Standard zählt, was nach dem Präfix kommt.

Drei Regeln tragen den größten Teil:

Nach Funktion benennen, nicht nach Hardware. bFoerderband3Lauft überlebt einen Lieferantenwechsel beim Motor. bSEW12345Lauft nicht. Die Variable überlebt die Komponente.

Das Anlagen-Kennzeichensystem spiegeln. Heißt es im R&I-Fließbild M-301, gehört M301 in den Variablennamen — kein zweites, paralleles Benennungsuniversum, das nur der Programmierer versteht. Diese eine Regel spart bei der Inbetriebnahme mehr Zeit als jede andere.

Zugehörigkeit kodieren, nicht Speicherort. Ein Name soll sagen, wozu etwas gehört (Foerderband3_MotorLauft), nicht wo es zufällig liegt (DB12_Bit3). Strukturen wandern, Bedeutung nicht.

2.2.Ebene 2: Der Schnittstellenvertrag

Hier verdient ein Standard sein Geld. Für jeden wiederverwendbaren Funktionsbaustein wird einmal entschieden und aufgeschrieben:

• Was ist an der Schnittstelle Pflicht? Die meisten Hausstandards verlangen mindestens eine Freigabe, einen Störausgang und ein Statuswort. Wenn jeder Baustein dieselbe Form hat, kann übergeordnete Logik alle gleich behandeln.
• Wem gehören die Instanzdaten? Instanz-DBs gehören der aufrufenden Ebene, nicht dem Autor des Bausteins.
• Worauf darf der Baustein zugreifen? Ein wiederverwendbarer Baustein, der globale Merker schreibt, ist nicht wiederverwendbar — er ist eine Tretmine. Die Regel „ein Bibliotheksbaustein liest und schreibt ausschließlich über seine Schnittstelle“ ist in den meisten Standards die wertvollste Zeile.
• Wie werden Störungen gemeldet? Einen Mechanismus wählen und überall anwenden. Viele Teams nutzen ein Statuswort nach NAMUR NE 107, damit die Diagnose anlagenweit gleich aussieht.

(*
  Schnittstellenvertrag für jeden Bibliotheksbaustein dieses Standards:
    IN   : bFreigabe        — keine Aktion solange FALSE
    IN   : stConfig         — alle Parameter, keine magischen Zahlen im Baustein
    OUT  : bBereit, bStoerung
    OUT  : wStatusNAMUR     — einheitliche Diagnose in der ganzen Anlage
  Der Baustein liest und schreibt nichts außerhalb dieser Schnittstelle.
*)

So sieht das in einem realen Projekt aus — die Gruppennummern ordnen die Bausteine nach Anlagenteil, und der Antriebsbaustein führt genau die Schnittstelle, die oben als Vertrag steht:

2.3.Ebene 3: Eine Bibliothek, kein Ordner mit Kopien

Der Unterschied zwischen einem Standard und einer Gewohnheit ist, ob die Bausteine irgendwo mit einer Version liegen.

• Eine einzige Quelle. Ein Bibliotheksbaustein existiert genau einmal. Projekte referenzieren ihn, sie kopieren ihn nicht.
• Versionierung mit Release-Disziplin. Eine Bibliotheksversion wird freigegeben, nicht bearbeitet. Braucht ein Projekt eine Änderung, bekommt es entweder eine neue Bibliotheksversion oder einen projektspezifischen Baustein, der ausdrücklich als solcher gekennzeichnet ist.
• Ein Änderungsprotokoll je Baustein. Nicht je Projekt — je Baustein, denn das ist die Einheit, die wiederverwendet wird.
• Ein definierter Ausnahmeweg. Jeder Standard wird irgendwann verletzt. Ein Standard ohne definierten Weg zur Abweichung wird still umgangen, und das ist das schlechteste Ergebnis. Schreiben Sie auf, wer eine Ausnahme genehmigt und wo sie festgehalten wird.

2.4.Ebene 4: Durchsetzung, die niemanden ausbremst

Ein Standard, den niemand prüft, ist ein Dokument, kein Standard. Drei Stufen, nach Aufwand geordnet:

Werkzeuge. TIA Portal ab V18 bringt einen Code Quality Check mit, der Verstöße gegen Namenskonventionen automatisch meldet. Er prüft Ihren Schnittstellenvertrag nicht, nimmt aber den mühsamsten Teil eines Reviews kostenlos ab.

Review-Checkliste. Fünf bis sieben Ja/Nein-Fragen, keine Abhandlung. Geht jeder Bibliotheksbaustein ausschließlich über seine Schnittstelle? Hat jede nicht selbsterklärende Konstante eine Quelle? Ist der Störmechanismus der standardisierte? Eine Checkliste, die zehn Minuten kostet, wird benutzt; eine, die eine Stunde kostet, nicht.

Automatische Strukturprüfung. Mit TIA Openness lässt sich ein Projekt in ein Textformat exportieren und programmatisch prüfen — Baustein-Benennung, Schnittstellenform, verbotene Globalzugriffe. Das lohnt sich, sobald die Bibliothek stabil ist, nicht vorher.

3.Was ein Standard bewusst nicht tun sollte

Überstandardisierung ist ein realer Fehlermodus und schwerer rückgängig zu machen als gar kein Standard.

• Nicht die Sprache je Bausteintyp vorschreiben. Die Wahl fällt je Aufgabe — der Standard soll regeln, wie sie begründet wird, nicht sie diktieren. Welche Sprache wofür taugt, steht in den fünf IEC-61131-3-Sprachen.
• Nicht die interne Umsetzung vorgeben. Der Vertrag ist die Schnittstelle. Wie ein Baustein seine Aufgabe intern löst, ist Sache des Autors.
• Den Standard nicht einfrieren. Ein Standard, der sich in drei Jahren nicht geändert hat, ist nicht stabil, sondern unbenutzt.

4.Zur Einordnung: „Top 20 Secure PLC Coding Practices“

Wer nach SPS-Programmierstandards sucht, stößt darauf. Es lohnt zu wissen, was es ist — und was nicht.

Es ist eine Community-Initiative, die sich gezielt mit der Sicherheitshärtung von Steuerungslogik befasst: Eingangsvalidierung, Plausibilitätsprüfungen, Überwachung auf unerwartete Werte, Beschränkung dessen, was die SPS von außen annimmt. Fachlich wertvoll und mit der EU-Regulatorik zu Maschinen und Cyberresilienz zunehmend relevant.

Aber es ist eine andere Achse als das, was dieser Artikel behandelt. Es beantwortet „wie mache ich meine Logik schwerer missbrauchbar“, nicht „wie mache ich mein Projekt für den nächsten Ingenieur wartbar“. Ein Team braucht beides, und keines ersetzt das andere. Wer die Security-Liste als allgemeinen Programmierstandard behandelt, lässt die Wartbarkeitsfragen offen.

5.Einen Standard in eine Bestandsanlage einführen

Der häufigste Grund, warum Standards nie entstehen: Der Bestand ist zu groß zum Umstellen, also fängt niemand an.

Was funktioniert, ist gar nichts umzustellen:

1. Den Standard nur auf neue Bausteine anwenden. Ab heute folgt alles Neue ihm. Nichts Altes wird angefasst.
2. Bei Berührung nachziehen. Muss ein Baustein ohnehin geändert werden, wird er im selben Zug auf den Standard gehoben. Über zwei, drei Projekte erfasst das genau die Bausteine, die zählen — die, die angefasst werden.
3. Niemals umstellen um des Umstellens willen. Einen Baustein neu zu schreiben, der seit acht Jahren unverändert läuft, erzeugt Risiko und bringt nichts. Bausteine, die niemand anfasst, muss auch niemand lesen.
4. Die Grenze dokumentieren. Eine Zeile je Baustein, ob er dem aktuellen Standard folgt, erspart dem nächsten Ingenieur das Raten.

Das kostet vorab nichts und verzinst sich. Ein Komplettumstellungs-Projekt bleibt dagegen erfahrungsgemäß auf halbem Weg stehen und hinterlässt einen Bestand mit zwei Standards statt einem — messbar schlechter als der Ausgangszustand.

6.Fazit

• Eine Präfix-Tabelle ist kein Standard. Am Schnittstellenvertrag entscheidet sich die Wartbarkeit.
• Nach Funktion benennen und das Anlagenkennzeichen spiegeln — die Variable überlebt die Komponente.
• Eine Bibliothek mit Versionen und Änderungsprotokoll macht aus einer Gewohnheit einen Standard.
• Den Ausnahmeweg definieren, sonst wird still abgewichen.
• Nur auf neue und ohnehin berührte Bausteine anwenden. Komplettumstellungen bleiben stecken, schrittweise Einführung verzinst sich.

7.Weiterführende Artikel

• SPS-Programmierung: 8 Best Practices für sauberen, wartbaren Code – die Grundlagen, inklusive vollständiger Präfix-Tabelle
• SPS-Dokumentation: Was hineingehört, was bei der Übergabe zählt – wie sich ein Standard bei der Übergabe zeigt
• Die 5 SPS-Programmiersprachen nach IEC 61131-3 – je Aufgabe wählen, statt die Wahl wegzustandardisieren