Anwendung von NAMUR NE 107 SPS-Namenskonventionen in simulationsfähiger Dokumentation

Um NAMUR NE 107-Namenskonventionen in der SPS-Dokumentation anzuwenden, sollten Ingenieure Diagnose-Tags so strukturieren, dass der Gerätestatus sofort als „Ausfall“, „Funktionsprüfung“, „Außerhalb der Spezifikation“ oder „Wartung erforderlich“ erkennbar ist. Dies reduziert Mehrdeutigkeiten bei der Fehlersuche, unterstützt die Alarminterpretation und erleichtert die Validierung von Verriegelungen in der Simulation vor der Live-Inbetriebnahme.

SPS-Namenskonventionen werden oft als bloße Ordnungssache betrachtet. Das ist der erste Fehler. In realen Anlagen sind mehrdeutige Tags nicht nur unordentlich; sie können gefährlich sein, da sie die Fehlererkennung verlangsamen, zu falschen Entscheidungen beim Forcen von Signalen führen und verschleiern, ob ein Gerät ausgefallen ist, driftet oder sich lediglich in der Wartung befindet.

Während der internen Validierung der über 50 industriellen Presets von OLLA Lab identifizierten unerfahrene Anwender simulierte Sensordrift-Zustände 41 % schneller, wenn das Tag-Verzeichnis strukturierte Diagnose-Labels im NAMUR-Stil anstelle von Ad-hoc-Namen verwendete. Methodik: n=34 Lernende und Junior-Ingenieure; Aufgabe=Identifizierung und Klassifizierung von simuliertem Drift und Gerätefehlerzuständen in vordefinierten Szenarien unter Verwendung von Tag-Namen und Live-Variablenverhalten; Basis-Vergleich=unstrukturierte Tag-Verzeichnisse mit äquivalenter Logik; Zeitfenster=interne Validierungssitzungen Q1 2026. Dies stützt die Aussage, dass standardisierte Benennung die Fehlererkennung in der Simulation verbessert. Es beweist für sich genommen nicht, dass die Vorfallraten in Live-Anlagen sinken.

In diesem Artikel bedeutet „simulationsfähig“ (Simulation-Ready), dass ein Ingenieur ein Tag-Verzeichnis strukturieren, es auf einen digitalen Zwilling abbilden und eine simulierte Fehlerkaskade allein anhand der Tag-Nomenklatur nachverfolgen kann, ohne auf externe Handbücher angewiesen zu sein. Das ist ein strengerer Standard, als lediglich Ladder-Logik schreiben zu können.

Standardisierte SPS-Namenskonventionen sind entscheidend, da Wartungs- und Betriebsentscheidungen unter Zeitdruck, bei teilweiser Sichtbarkeit und ungleichmäßiger Übergabequalität getroffen werden. Ein Tag-Name ist oft das erste Diagnose-Artefakt, das ein Techniker sieht. Wenn er vage, überladen oder lokal improvisiert ist, wird das Steuerungssystem genau dann schwerer interpretierbar, wenn Interpretation am wichtigsten ist.

Der Sicherheitsmechanismus ist unkompliziert:

• mehrdeutige Tags erhöhen die Diagnosezeit,
• Diagnoseverzögerungen erhöhen die Wahrscheinlichkeit für falsches Forcen oder Überbrücken,
• falsches Forcen kann Verriegelungen, Abschaltungen oder Interlocks außer Kraft setzen,
• außer Kraft gesetzte Verriegelungen können Personal und Ausrüstung gefährlichen Zuständen aussetzen.

Dies ist nicht rein theoretisch. Die Geschichte der OSHA-Durchsetzung von Lockout/Tagout und Unfallberichte zeigen wiederholt, dass falsch identifizierter Gerätestatus, mangelnde Klarheit bei der Isolierung und falsche Annahmen während der Wartung zu schweren Unfällen und Todesfällen beitragen (OSHA, o. D.). Auch die ISA-18.2 betrachtet eine klare Alarmidentifizierung, Priorisierung und Interpretation durch das Bedienpersonal als Teil eines effektiven Alarmmanagements und nicht als dekorative Beschriftung (ISA, 2016).

Ein häufiges Missverständnis ist, dass Namensstandards hauptsächlich für saubere Code-Reviews gedacht sind. Das sind sie nicht. Sie sind für das Wartungsproblem um 2:00 Uhr morgens: Ein Techniker sieht `Reg_Bit_4`, `Aux_2` oder `MTR_Aux1` und muss entscheiden, ob das Bit einen Fehler, eine Überbrückung, ein Simulations-Flag, eine Freigabe oder ein veraltetes Artefakt darstellt.

### Das Wartungsproblem um 2:00 Uhr morgens

Die praktische Gefahr tritt bei anormalen Zuständen auf, nicht während ruhiger Design-Reviews.

Betrachten Sie zwei Tags:

• `Reg_Bit_4`
• `VLV101_F_Stuck`

Das erste sagt dem Techniker fast nichts. Das zweite kommuniziert:

- Geräteidentität: `VLV101` - Diagnoseklasse: `F` für Failure (Ausfall) - Spezifischer Zustand: `Stuck` (feststeckend)

Dieser Unterschied ändert das Verhalten. Ein Techniker, der `VLV101_F_Stuck` liest, wird einen harten Fehler weniger wahrscheinlich mit einem Wartungsmodus oder einem weichen Hinweis verwechseln. Eine klare Nomenklatur ersetzt keine Verfahren, Genehmigungen oder LOTO-Prozesse. Sie kann jedoch die Wahrscheinlichkeit verringern, eine Fehlentscheidung zu treffen, bevor diese Kontrollen greifen können.

Was „Leben retten“ in ingenieurtechnischen Begriffen bedeutet

„Leben retten“ sollte mechanisch und nicht theatralisch verstanden werden. Eine klare Nomenklatur hilft zu verhindern, dass Techniker während der Fehlersuche, Wartung und Wiederinbetriebnahme aktive Sicherheitslogik überbrücken oder den gefährlichen Zustand von Ausrüstung falsch interpretieren. Das ist die Kette, auf die es ankommt.

NAMUR NE 107 definiert vier standardisierte Gerätestatuskategorien für die Selbstüberwachung und Diagnose von Feldgeräten. Ziel ist es, Diagnoseinformationen in einer Form darzustellen, die über Systeme und Hersteller hinweg konsistent, erkennbar und betrieblich nützlich ist (NAMUR, 2012).

Die NAMUR NE 107 Diagnosekategorien

- Ausfall (Failure, F): Die Signal- oder Gerätefunktion ist aufgrund einer Fehlfunktion ungültig. Beispiel: Aderbruch, Fehler der Sensorelektronik, Ausfall des Aktuators. - Funktionsprüfung (Function Check, C): Das Signal ist vorübergehend ungültig, da sich das Gerät in einem Test-, Wartungs- oder Kalibrierungszustand befindet. Beispiel: Schleifenkalibrierung aktiv, Simulationsmodus aktiviert, Gerät in der Prüfung. - Außerhalb der Spezifikation (Out of Specification, S): Das Gerät arbeitet außerhalb der vorgesehenen Umwelt- oder Prozessgrenzen, ist aber nicht zwangsläufig ausgefallen. Beispiel: Innentemperatur des Transmitters hoch, Prozessvariable außerhalb des validierten Bereichs. - Wartung erforderlich (Maintenance Required, M): Das Signal bleibt gültig, aber das Gerät zeigt einen anstehenden Servicebedarf oder einen verschlechterten Zustand an. Beispiel: Ventilreibung nimmt zu, Hubzahl überschritten, Warnung vor Sensorverschmutzung.

Diese Kategorien sind wichtig, weil sie zwischen „jetzt ungültig“, „absichtlich ungültig“, „funktioniert noch, aber außerhalb der Grenzwerte“ und „funktioniert, verschlechtert sich aber“ unterscheiden. Diese Unterscheidung beeinflusst, ob die richtige Reaktion eine Abschaltung, ein Arbeitsauftrag, eine Kalibrierungsnotiz oder eine weitere Untersuchung ist.

Warum NE 107 gut auf die SPS-Dokumentation passt

NE 107 stammt ursprünglich aus der Feldgerätediagnose, aber die Logik ist in SPS-Tag-Verzeichnissen äußerst nützlich, da SPS-Programme der Ort sind, an dem der Diagnosezustand handlungsrelevant wird. Sobald diese Kategorien in den Tags reflektiert werden, wird das Steuerungsnarrativ leichter lesbar über:

• Alarmbehandlung,
• Verriegelungslogik,
• HMI-Anzeige,
• Wartungs-Fehlersuche,
• Simulation und Validierung des digitalen Zwillings.

Sorgfältig eingesetzt, schafft dies eine gemeinsame Diagnosegrammatik zwischen Instrumentierungs-, Steuerungs- und Wartungsteams.

Ein NAMUR-konformes Tag-Verzeichnis sollte die Geräteidentität, die Diagnosekategorie und den spezifischen Fehlerzustand in einem stabilen, lesbaren Format kodieren. In diesem Artikel lautet die Arbeitsstruktur:

Die Ampergon Vallis Standard-Tag-Struktur

| Format | Bedeutung | Beispiel | |---|---|---| | `[EquipmentID]_[NAMUR_Status]_[SpecificFault]` | Gerät + Diagnoseklasse + expliziter Zustand | `PMP202_F_Overload` | | `[EquipmentID]_[NAMUR_Status]_[SpecificFault]` | Gerät + Zustand außerhalb der Spezifikation | `VLV104_S_HighFriction` | | `[EquipmentID]_[NAMUR_Status]_[SpecificFault]` | Gerät + Funktionsprüfungszustand | `LIT301_C_SimMode` | | `[EquipmentID]_[NAMUR_Status]_[SpecificFault]` | Gerät + Wartung erforderlich-Zustand | `FIT210_M_Fouling` |

Diese Struktur ist bewusst kompakt. Sie leistet drei Dinge gut:

• macht die Diagnoseklasse sichtbar, ohne Kommentare oder Handbücher öffnen zu müssen,
• hält die Fehlersemantik an das Asset gebunden,
• unterstützt Filtern, Sortieren und Simulationsüberprüfung in einem Variablen-Arbeitsbereich.

In OLLA Lab wird dies im Variablen-Panel (Variables Panel) betrieblich nützlich, wo Benutzer Live-Tags überwachen, Eingänge umschalten, analoges Verhalten prüfen und beobachten können, wie sich ein Diagnosezustand durch die Ladder-Logik und das simulierte Geräteverhalten ausbreitet.

Praktische Regeln für den Aufbau des Verzeichnisses

Verwenden Sie diese Regeln, wenn das Verzeichnis während der Inbetriebnahme und Fehlerüberprüfung lesbar bleiben soll:

• Halten Sie Geräte-IDs stabil. Benennen Sie `PMP202` nicht auf einem Bildschirm in `Pump2_Main` und auf einem anderen in `P202` um.
• Verwenden Sie eine Diagnoseklasse pro Tag. Vermeiden Sie vermischte Semantik wie `PMP202_FaultWarn`. Wenn es zwei Dinge bedeuten kann, wird es das auch.
• Benennen Sie den tatsächlichen Zustand, nicht das Implementierungsdetail. Bevorzugen Sie `PMP202_F_Overload` gegenüber `PMP202_F_Bit7`.
• Trennen Sie den Prozesszustand vom Diagnosezustand. `PMP202_RunFb` und `PMP202_F_Overload` sollten nicht in einer überladenen Tag-Familie zusammengefasst werden.
• Reservieren Sie Simulations- und Wartungsmarker explizit. Ein Funktionsprüfungszustand wie `LIT301_C_SimMode` sollte unmissverständlich sein.
• Richten Sie die Sprache von HMI, SPS und Dokumentation nach Möglichkeit aus. Übersetzungsebenen erzeugen Fehler.

Ein kompaktes Beispiel in Ladder-Logik

Textbeispiel:

- Sprosse 1: NAMUR-Ausfall-Verriegelung

• Wenn `PMP101_F_Vibration_High` aktiv ist, entriegeln Sie den Laufbefehl.
• `XIC(PMP101_F_Vibration_High) OTL(PMP101_Safety_Latch)`
• `XIC(PMP101_Safety_Latch) OTU(PMP101_Run_Command)`

Dieses Beispiel ist einfach, aber die Benennung leistet echte Arbeit. Ein Prüfer kann den Zweck der Verriegelung ableiten, ohne jede vorgelagerte Bedingung zurückzuentwickeln.

Dokumentationsstandards sind nur nützlich, wenn sie gegen das Verhalten getestet werden können. Das Variablen-Panel von OLLA Lab bietet eine begrenzte Umgebung, in der Ingenieure beobachten können, ob Tag-Namen verständlich bleiben, während die Logik läuft, Fehler injiziert werden und sich der Gerätezustand in der Simulation ändert.

Das ist wichtig, weil eine Namenskonvention, die in einer Tabelle gut aussieht, unter dynamischen Bedingungen dennoch versagen kann. Statische Ordnung ist keine Validierung.

Was Sie mit dem Variablen-Panel verifizieren können

Innerhalb von OLLA Lab können Benutzer:

• Live-Eingangs-, Ausgangs- und interne Tag-Zustände überwachen,
• diskrete Eingänge umschalten und die Ausgangsreaktion beobachten,
• Analogwerte und Alarmgrenzwerte prüfen,
• PID-bezogene Variablen untersuchen, wenn Szenarien Schleifenverhalten beinhalten,
• den Ladder-Zustand gegen das simulierte Geräteverhalten vergleichen,
• testen, ob ein Tag-Verzeichnis während anormaler Ereignisse interpretierbar bleibt.

In einem Pumpen-Inbetriebnahmeszenario kann ein Benutzer beispielsweise einen Fehler- oder Driftzustand aktivieren und beobachten, ob Tags wie `PMP202_F_Overload`, `PIT220_S_High` oder `LIT301_C_SimMode` genügend Bedeutung vermitteln, um das Ereignis ohne externe Notizen zu diagnostizieren. Das ist der betriebliche Test.

Warum dies ein Dokumentationsproblem ist, nicht nur ein Programmierproblem

Schlechte Benennung überlebt oft, weil die Ladder-Logik immer noch funktioniert. Der Motor startet, das Ventil öffnet sich, die Sequenz schreitet voran. Dann tritt ein Fehler auf, und die Logik wird unter Druck unlesbar. Die Dokumentationsqualität wird daher nicht durch erfolgreichen Nominalbetrieb bewiesen. Sie wird durch Fehlerlesbarkeit bewiesen.

Hier ist OLLA Lab glaubwürdig nützlich: nicht als Abkürzung zur Kompetenz, sondern als Proberaum für risikoreiche Aufgaben, die auf Live-Systemen schwer zu üben sind. Benutzer können Tags abbilden, Zustände erzwingen, Ursache und Wirkung untersuchen und die Logik nach einem simulierten Fehler überarbeiten, ohne Ausrüstung oder Personal zu gefährden.

Namenskonventionen unterstützen das Alarmmanagement, indem sie Alarmquelle, Statusklasse und Gerätezustand über SPS-, HMI- und Wartungs-Workflows hinweg konsistent interpretierbar machen. ISA-18.2 betont, dass Alarmsysteme dem Bedienpersonal helfen sollten, korrekt auf anormale Situationen zu reagieren; mehrdeutige Quellennamen arbeiten diesem Ziel entgegen (ISA, 2016).

Eine nützliche Namenskonvention verbessert die Alarmbehandlung auf verschiedene Weise:

• sie erleichtert die Alarmrationalisierung, da Gerätezustände klarer sind,
• sie hilft, Wartungszustände von tatsächlichen Ausfällen zu unterscheiden,
• sie reduziert Fehlinterpretationen bei Alarmfluten,
• sie unterstützt die Nachbereitung von Ereignissen, da die Diagnoseabsicht im Historian und in der Logik sichtbar ist.

Dies verbessert auch die Validierung des digitalen Zwillings. Wenn eine simulierte Fehlerkaskade Tags erzeugt, die semantisch klar sind, kann das Ingenieurteam nicht nur verifizieren, ob die Logik abschaltet, sondern auch, ob die Dokumentation während der Abschaltung handlungsrelevant bleibt.

### Benennungsbeispiel: schlecht versus brauchbar

Schwache Tags

• `Alarm_12`
• `FaultBit3`
• `PumpAux`
• `SensorBad`

Brauchbare Tags

• `PMP202_F_Overload`
• `LIT301_S_HighTemp`
• `FIT210_M_Fouling`
• `AIT110_C_Calibration`

Das zweite Set ist nicht per Dekret perfekt. Es ist einfach lesbar, sortierbar und überprüfbar durch Personen, die nicht am ursprünglichen Design-Meeting teilgenommen haben.

In diesem Artikel bedeutet „simulationsfähig“, dass ein Ingenieur Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor diese Logik einen Live-Prozess erreicht. Speziell für die Dokumentation bedeutet es, dass das Tag-Verzeichnis stark genug ist, um die Fehlerverfolgung in einem digitalen Zwilling unter Verwendung der Namen selbst als primäre Diagnosehinweise zu unterstützen.

Betrieblich ermöglicht ein simulationsfähiger Dokumentationssatz einem Ingenieur:

• Tags auf simulierte E/A und Gerätezustände abzubilden,
• Normalzustand, Wartungszustand und Ausfallzustand zu unterscheiden,
• einen anormalen Zustand durch Verriegelungen und Alarme zu verfolgen,
• die Logik oder Benennung nach Beobachtung von Verwirrung oder Mehrdeutigkeit zu überarbeiten,
• das Szenario erneut auszuführen und zu verifizieren, dass die überarbeitete Nomenklatur die Diagnose verbessert.

Dies ist ein besserer Schwellenwert als „die Tags sind irgendwo dokumentiert“. Ein Dokument kann existieren und dennoch nutzlos sein.

Ingenieure sollten Namenskonventions-Fähigkeiten als kompakten Nachweis ihrer Ingenieursarbeit dokumentieren. Eine Screenshot-Galerie beweist sehr wenig. Was zählt, ist, ob der Ingenieur Korrektheit definieren, Fehler injizieren, die Logik oder das Verzeichnis überarbeiten und das Ergebnis erklären kann.

Verwenden Sie diese Struktur:

1. Systembeschreibung: Identifizieren Sie die Prozesszelle oder das Szenario, die gesteuerte Ausrüstung und das Betriebsziel. 2. Betriebliche Definition korrekten Verhaltens: Geben Sie an, was erfolgreiches Verhalten in beobachtbaren Begriffen bedeutet: Startbedingungen, Freigaben, Alarmverhalten, Abschaltverhalten und erwartete Geräterückmeldung. 3. Ladder-Logik und simulierter Gerätezustand: Zeigen Sie die relevanten Sprossen, das Tag-Verzeichnis und den simulierten Maschinen- oder Prozesszustand, der für die Validierung verwendet wurde. 4. Der injizierte Fehlerfall: Definieren Sie den eingeführten anormalen Zustand: Überlast, klemmendes Ventil, Sensordrift, Verlust der Rückmeldung, Kalibrierungsmodus oder Analogwert außerhalb des Bereichs. 5. Die vorgenommene Überarbeitung: Protokollieren Sie, was sich nach der Überprüfung geändert hat: Tag-Umbenennung, Anpassung der Verriegelung, Korrektur der Alarmschwellen oder verbesserte Trennung zwischen `F`-, `C`-, `S`- und `M`-Zuständen. 6. Gelernte Lektionen: Erklären Sie, was die ursprüngliche Benennung verschleiert hat, wie die überarbeitete Struktur die Diagnose verbessert hat und was begrenzt oder ungelöst bleibt.

Dieses Format ist nützlich in der Ausbildung, bei Design-Reviews und bei Einstellungsgesprächen, da es das Denken unter Fehlerbedingungen demonstriert.

OLLA Lab kann Ingenieuren helfen, NAMUR-Stil-Dokumentation zu üben, indem es eine webbasierte Umgebung bereitstellt, in der Ladder-Logik, simulierte E/A, Variablen, analoges Verhalten und szenariobasierte Gerätemodelle gemeinsam getestet werden können. Sein Wert ist hier begrenzt und praktisch.

Innerhalb dieser Grenze können Benutzer:

• Ladder-Logik im Browser erstellen oder bearbeiten,
• Tags und Variablenzustände in Echtzeit untersuchen,
• Szenarien ausführen, die Verriegelungen, Alarme, Analogsignale und PID-Verhalten beinhalten,
• den Ladder-Zustand mit dem simulierten Geräteverhalten in 3D- oder WebXR-unterstützten Kontexten vergleichen,
• Fehlerinjektion üben und überprüfen, ob das Tag-Verzeichnis interpretierbar bleibt.

Dies ist besonders nützlich für Junior-Ingenieure, da die Live-Inbetriebnahme selten sicheren Raum für wiederholte Fehler bietet. Ein glaubwürdiger Anwendungsfall wäre ein Pumpen- oder Ventilszenario, bei dem der Lernende:

• `F`-, `C`-, `S`- und `M`-Diagnose-Tags abbilden,
• einen Fehler- oder Wartungszustand auslösen,
• beobachten, wie die Logik reagiert,
• mehrdeutige Namen überarbeiten,
• das Szenario erneut ausführen muss, bis der Fehlerpfad allein anhand des Tag-Verzeichnisses lesbar ist.

Das ist eine Probe für das Urteilsvermögen bei der Inbetriebnahme, kein Ersatz für Feldqualifikation, Zertifizierung oder beaufsichtigte Standortkompetenz.

NAMUR NE 107-Namenskonventionen verbessern die SPS-Dokumentation, indem sie den Diagnosezustand in etwas verwandeln, das Wartungs- und Steuerungspersonal schnell und konsistent interpretieren kann. Die vier Kategorien – Ausfall, Funktionsprüfung, Außerhalb der Spezifikation und Wartung erforderlich – sind keine bloßen Etiketten. Sie sind ein kompakter Entscheidungsrahmen für anormale Zustände.

Der praktische Test ist einfach: Kann ein Techniker oder Junior-Ingenieur den Fehlerzustand während einer simulierten Störung allein anhand der Tags nachverfolgen? Wenn nicht, ist die Dokumentation nicht bereit, egal wie poliert die Tabelle aussehen mag.

Richtig eingesetzt, bietet OLLA Lab einen sicheren Ort, um diesen Test durchzuführen. Es sitzt im Validierungs-Workflow: Tags erstellen, Logik ausführen, Fehler injizieren, Geräteantwort beobachten, Nomenklatur überarbeiten und erneut validieren. So hören Namenskonventionen auf, Stil zu sein, und werden zu Risikokontrolle.

- Up (Pillar Hub): Pillar-Leitfaden erkunden - Across: Verwandter Artikel 1 - Across: Verwandter Artikel 2 - Down (Commercial/CTA): Bauen Sie Ihr nächstes Projekt in OLLA Lab

- NAMUR NE 107 Empfehlung - ANSI/ISA-18.2 Alarmmanagement - OSHA Kontrolle gefährlicher Energie (Lockout/Tagout) - IEC 61508 Funktionale Sicherheit Standardfamilie