Die Prozessindustrie überwacht Anlagenwerte seit Jahrzehnten in Echtzeit – Historian-Systeme wie PI-Systeme leisten das schon lange zuverlässig. Ein Unified Namespace (UNS) in der Prozessindustrie ersetzt diese Systeme nicht. Er bricht stattdessen die starre Automatisierungspyramide auf und macht Daten aus Prozessleitsystem, Sicherheitssystem, Historian und MES kanalübergreifend verfügbar, statt sie über brüchige Punkt-zu-Punkt-OPC-Brücken zwischen den Ebenen zu schleusen. Genau das ist auch der Kerngedanke der NAMUR Open Architecture (NOA): ein zweiter, unabhängiger Kanal neben dem Kernprozessleitsystem.
Dieser Artikel zeigt, was einen Unified Namespace in der Prozessindustrie von einer generischen Manufacturing-Architektur unterscheidet. Der Artikel liefert branchenspezifische Use Cases für KI und digitalen Zwilling sowie konkrete Best Practices. Die technischen Grundlagen des UNS erklärt der Artikel Was ist der Unified Namespace (UNS)?
Unified Namespace Anforderungen in der Prozessindustrie
Digitalisierungsprojekte in der Prozessindustrie stehen vor Anforderungen, die sich von diskreter Fertigung deutlich unterscheiden. Die folgenden Treiber bestimmen, wie Daten modelliert, gespeichert und ausgewertet werden müssen.
Konzeptionelle und regulatorische Treiber: ISA-88, NAMUR NOA und IEC 61511
ISA-88 (S88) strukturiert Batch-Prozesse feingranularer als das reine Standortmodell aus ISA-95: Process Cell, Unit, Equipment Module und Control Module bilden eine eigene physische Hierarchie, ergänzt um Rezeptphasen wie Charge, Reaktion, Entladung und Reinigung. Die NAMUR Open Architecture liefert dazu das konzeptionelle Gegenstück auf Kommunikationsebene – einen zweiten Kanal für Monitoring und Optimierung, der unabhängig vom Kernprozessleitsystem arbeitet. IEC 61511 wiederum regelt Safety Instrumented Systems (SIS): Ein Sicherheitsinstrumentiertes System muss funktional und organisatorisch vom Basic Process Control System getrennt bleiben. Ein UNS darf SIS-Daten deshalb nur spiegeln, niemals steuern.
Diese drei Konzepte greifen ineinander. ISA-88 modelliert, was in der Anlage passiert. NOA modelliert, wie Daten sicher nach außen fließen. IEC 61511 zieht die rote Linie, die dabei nicht überschritten werden darf.
Was die Prozessindustrie technisch besonders macht
Eine Prozessanlage kombiniert oft kontinuierliche und Batch-Prozesse in derselben Produktionslinie. Eine Destillationskolonne läuft wochenlang durch, während ein Batch-Reaktor daneben Rezept für Rezept abarbeitet. Beide Prozessarten brauchen unterschiedliche Datenmodelle im selben UNS. Hinzu kommt die Alarmflut: Nach EEMUA 191 gilt eine Anlage als beherrschbar, wenn ein Bediener im Mittel nicht mehr als einen Alarm pro zehn Minuten bearbeiten muss. In der Praxis reißen viele Anlagen diesen Wert bei Störungen um ein Vielfaches. Diese Eigenschaften prägen, wie ein Unified Namespace in der Prozessindustrie modelliert werden muss: Rezeptdaten, SIS-Status und Alarmkontext sind eigenständige Datenobjekte, keine Zusatzfelder in einem generischen Sensor-Payload.
Prozessindustrie-spezifische Topic-Struktur
In einem Unified Namespace in der Prozessindustrie bleibt die physische Hierarchie stabil: Werk, Process Cell, Unit, Equipment Module, Messgröße. Sie ändert sich nicht mit der aktuell laufenden Charge. Das folgt denselben ISA-95-Grundsätzen wie in MQTT Topic Namespace Best Practices, erweitert um die ISA-88-Ebenen für Batch-Einheiten. Branchenspezifisch ist auch hier nicht die Topic-Hierarchie selbst, sondern die Frage, wo Rezept-, SIS- und Alarmdaten im UNS abgelegt werden.
Typische Topic-Hierarchie, unabhängig von der Charge:
ludwigshafen/pc12/k7/druck-monitoring/istwertludwigshafen/pc12/k7/druck-monitoring/status
Batch- und Sicherheitsereignisse erhalten dagegen eigene, einmalige Topics:
ludwigshafen/pc12/r204/batch/CHG-2026-0718-A17/batch-recordludwigshafen/pc12/r204/sis/sif-101/status
Die folgende Datenmodellierung weist drei prozessindustriespezifische Eigenschaften auf:
- Kontinuierliche Messwerte bleiben unabhängig von der Charge: Ein Drucksensor an der Kolonne publiziert fortlaufend auf einem festen Topic, ohne Chargen-ID im Pfad.
- Ein Batch durchläuft mehrere Rezeptphasen. Er erhält ein eigenständiges Topic je Charge, weil jede Charge einen einzeln auditierbaren Datensatz nach ISA-88 darstellt.
- Der SIS-Status ist inhärent pro Sicherheitsfunktion (Safety Instrumented Function, SIF). Er wird über die SIF-ID im Topic geführt und ausschließlich lesend aus dem SIS gespiegelt.
Die folgenden Use Cases zeigen diese Struktur an einer durchgängigen Beispielanlage: Werk Ludwigshafen, Process Cell PC-12, mit Batch-Reaktor R-204 und kontinuierlicher Destillationskolonne K-7.
UNS Use Cases und reale Beispiele in der Prozessindustrie
Die folgenden Use Cases zeigen, wie sich dieses Datenmodell in der Praxis auszahlt – von der klassischen Batch-Rückverfolgung bis zu KI-gestützten Erkenntnissen und digitalen Zwillingen.
Batch-Ausführung und Rezeptverfolgung nach ISA-88
Statt Chargendaten nachträglich aus Batch-Management-System, Historian und Laborexporten zusammenzuführen, liefert der Unified Namespace die vollständige Rezeptausführung einer Charge in Echtzeit. Rohstoffchargen, Rezeptphasen, Prozessparameter und Freigabestatus sind über die Chargen-ID direkt verknüpft. Ein Audit, der den kompletten Herstellungsnachweis einer Charge verlangt, wird damit zur Abfrage statt zum manuellen Rechercheprojekt.
Topic: ludwigshafen/pc12/r204/batch/CHG-2026-0718-A17/batch-record
JSON Payload:
{
"batchId": "CHG-2026-0718-A17",
"recipeId": "REC-INT-204",
"recipeVersion": "v3.2",
"processCellId": "PC-12",
"unitId": "R-204",
"rawMaterials": [
{
"material": "monomer_a",
"supplierLot": "LOT-MA-55210",
"quantityKg": 850
},
{
"material": "catalyst_x",
"supplierLot": "LOT-CX-11072",
"quantityKg": 12
}
],
"recipePhases": [
{
"phase": "charge",
"startTime": "2026-07-18T04:00:00Z",
"endTime": "2026-07-18T04:45:00Z"
},
{
"phase": "react",
"startTime": "2026-07-18T04:45:00Z",
"endTime": "2026-07-18T09:15:00Z",
"targetTempC": 140,
"targetPressureBar": 6.2
},
{
"phase": "discharge",
"startTime": "2026-07-18T09:15:00Z",
"endTime": "2026-07-18T09:50:00Z"
}
],
"productionSite": "plant-ludwigshafen",
"status": "released",
"isa88Record": "batch_record",
"timestamp": "2026-07-18T09:50:00Z"
}
NOA-konformer Monitoring- und Diagnosekanal
Zusätzliche Sensorik, die ausschließlich der Zustandsüberwachung dient, wird nach dem NOA-Prinzip über einen eigenen, vom Kernprozessleitsystem unabhängigen Kanal geführt. Ein zusätzlicher Drucksensor an der Kolonne liefert so Diagnosedaten für Monitoring und Optimierung, ohne in die Regelschleife des Prozessleitsystems einzugreifen. Wie der Unified Namespace diesen zweiten Kanal konkret umsetzt, beschreibt der Artikel Der Unified Namespace ermöglicht die NAMUR Open Architecture.
Topic: ludwigshafen/pc12/k7/druck-monitoring/istwert
JSON Payload:
{
"sensorId": "PT-K7-MON-02",
"unitId": "K-7",
"measurementType": "pressure",
"monitoringChannel": "noa_secondary",
"controlRelevant": false,
"valueBar": 4.85,
"limitMinBar": 4.0,
"limitMaxBar": 5.5,
"status": "within_limits",
"timestamp": "2026-07-18T10:00:00Z"
}
SIS-Status- und Proof-Test-Monitoring nach IEC 61511
Der Unified Namespace spiegelt den Status jeder Sicherheitsinstrumentierten Funktion (SIF) sowie deren Proof-Test-Fälligkeit lesend aus dem SIS. Das schafft Sichtbarkeit für Asset-Management und Auditvorbereitung. Die Sicherheitslogik selbst bleibt vollständig im SIS – der UNS besitzt keinerlei Schreibrechte auf Sicherheitsfunktionen und darf keinen Sicherheitspfad ersetzen.
Topic: ludwigshafen/pc12/r204/sis/sif-101/status
JSON Payload:
{
"sifId": "SIF-101",
"safetyFunction": "reactor_overpressure_trip",
"silRating": "SIL2",
"sisState": "healthy",
"lastProofTestDate": "2026-04-02",
"nextProofTestDue": "2027-04-02",
"writeAccessFromUns": false,
"dataSource": "sis_read_only_mirror",
"timestamp": "2026-07-18T00:00:00Z"
}
Alarm-Management-Datenaggregation nach EEMUA 191
Jeder Alarm publiziert Priorität, Grenzwert, Ist-Wert und Quittierstatus als eigenes Ereignis. Das erlaubt eine zentrale Auswertung der Alarmrate gegen den EEMUA-191-Zielwert, statt Alarmlisten manuell aus mehreren DCS-Stationen zusammenzutragen.
Topic: ludwigshafen/pc12/k7/alarm/ALM-20260718-0912/ereignis
JSON Payload:
{
"alarmId": "ALM-20260718-0912",
"tag": "PT-K7-01",
"priority": "high",
"eemua191Class": "priority_2",
"setpoint": 5.5,
"actualValue": 5.9,
"raisedAt": "2026-07-18T09:12:00Z",
"acknowledgedBy": "operator-042",
"acknowledgedAt": "2026-07-18T09:13:10Z",
"clearedAt": "2026-07-18T09:24:00Z",
"rationalizationStatus": "reviewed"
}
KI-Anwendungsfälle in der Prozessindustrie
KI-Anwendungsfälle für den Unified Namespace in der Prozessindustrie entfalten ihren Wert erst durch die Verknüpfung von Prozess-, Alarm- und Laborqualitätsdaten – nicht durch generische Anomalieerkennung.
Alarmflut-Mustererkennung und Root-Cause-Korrelation
Ein Modell gruppiert Alarme, die innerhalb eines kurzen Zeitfensters gemeinsam auftreten, und schlägt einen wahrscheinlichen Primäralarm vor. Das beschleunigt die Ursachenanalyse bei Störungen. Sicherheitsrelevante Alarme unterdrückt das Modell dabei nie automatisch – es liefert ausschließlich eine priorisierte Empfehlung für den Bediener.
Topic: ludwigshafen/pc12/ki/alarmflut-korrelation/EVENT-20260718-0912
JSON Payload:
{
"eventId": "EVENT-20260718-0912",
"model": "alarm-flood-correlation-v1.3",
"windowStart": "2026-07-18T09:10:00Z",
"windowEnd": "2026-07-18T09:18:00Z",
"groupedAlarms": [
"ALM-20260718-0910",
"ALM-20260718-0912",
"ALM-20260718-0915"
],
"probableRootCauseTag": "PT-K7-01",
"confidenceScore": 0.82,
"suppressesSafetyAlarm": false,
"recommendation": "flag_root_cause_tag_for_review",
"timestamp": "2026-07-18T09:19:00Z"
}
Soft-Sensor-Verfeinerung für Produktqualität
Inferenzmodelle für schwer messbare Qualitätsgrößen sind in der Prozessindustrie seit Jahren gängige APC-Praxis. Ein Modell im UNS erweitert diese Praxis, indem es zusätzlich Kontext aus Vorprodukt-Charge, Katalysatoralter und Instandhaltungshistorie einbezieht. Die offizielle Laborfreigabe bleibt davon unberührt – der Soft-Sensor liefert eine Frühindikation, ersetzt aber keine Laboranalyse.
Topic: ludwigshafen/pc12/k7/ki/soft-sensor/produktqualitaet
JSON Payload:
{
"unitId": "K-7",
"model": "soft-sensor-purity-v2.0",
"predictedPurityPercent": 99.4,
"confidenceIntervalPercent": 0.3,
"contributingFactors": [
{
"source": "upstream_batch",
"factor": "feed_composition_deviation_percent",
"value": 0.8
},
{
"source": "maintenance",
"factor": "catalyst_age_days",
"value": 42
}
],
"replacesLabAnalysis": false,
"timestamp": "2026-07-18T11:00:00Z"
}
Digitaler Zwilling in der Prozessindustrie
Der digitale Zwilling im Unified Namespace ist insbesondere dann interessant, sobald er neben Anlagenparametern auch rezeptur- und modulspezifische Prozessdaten integriert.
MTP-Modul-Zwilling für virtuelle Inbetriebnahme
Module Type Packages (MTP) beschreiben modulare Anlagenteile, sogenannte Process Equipment Assemblies, herstellerübergreifend standardisiert. Der digitale Zwilling simuliert ein neues Modul im Kontext der Gesamtanlage, bevor es physisch integriert wird. So lässt sich die Integration absichern, ohne die laufende Produktion zu unterbrechen.
Topic: ludwigshafen/pc12/zwilling/mtp-modul/simulation
JSON Payload:
{
"simulationId": "SIM-MTP-2026071801",
"peaId": "PEA-DOSIER-07",
"scenario": "new_module_integration_test",
"input": {
"dosingRateLPerMin": 12.5,
"interfaceProtocol": "opc_ua"
},
"predictedCycleTimeMin": 8.2,
"maxAllowedCycleTimeMin": 9.0,
"result": "sufficient",
"recommendedForLiveOperation": true,
"timestamp": "2026-07-17T22:00:00Z"
}
Batch-/Rezepturzwilling zur Parametervalidierung
Der digitale Zwilling simuliert Temperatur- und Druckverlauf einer Rezeptur, bevor ein neuer Parametersatz in die reale Produktion übergeht. So lässt sich die erwartete Ausbeute absichern, ohne eine reale Charge zu riskieren.
Topic: ludwigshafen/pc12/r204/zwilling/rezeptur/simulation
JSON Payload:
{
"simulationId": "SIM-REC-2026071802",
"recipeId": "REC-INT-204",
"scenario": "reduced_reaction_time_test",
"input": {
"targetTempC": 143,
"reactionTimeH": 4
},
"predictedYieldPercent": 96.8,
"minRequiredYieldPercent": 95.0,
"result": "sufficient",
"recommendedForLiveOperation": false,
"timestamp": "2026-07-17T21:00:00Z"
}
Best Practices für die UNS Einführung in der Prozessindustrie
Do
- Rezeptversion und Chargen-ID als Pflichtfelder modellieren: Sie gehören auf Batch-Ebene, nicht als Zusatzattribut irgendwo im Payload verstreut.
- SIS-Status sichtbar, aber isoliert führen: Der UNS spiegelt SIF-Status und Proof-Test-Termine, ohne Schreibzugriff auf das SIS zu erhalten.
- Alarmkontext mitführen: Priorität, Grenzwert und Quittierstatus gehören in den UNS, damit EEMUA-191-Auswertungen zentral möglich sind.
- Kalibrierstatus mitführen: Der Kalibrierstatus von Prozess- und Sicherheitssensoren gehört in den UNS, damit Audits die Messgenauigkeit lückenlos nachvollziehen können.
Avoid
- SIS-Logik über den UNS schließen oder ersetzen: Verstößt gegen die in IEC 61511 geforderte Trennung von Sicherheits- und Prozessleitsystem.
- Alarmdaten nur im lokalen DCS-Log belassen: Ohne Sichtbarkeit im UNS lässt sich die Alarmrate nicht zentral gegen EEMUA 191 auswerten.
- Rezeptparameter nur im Batch-Management-System pflegen: Erschwert die Verknüpfung mit Prozess- und Qualitätsdaten derselben Charge.
Fazit
Ein Unified Namespace in der Prozessindustrie ist mehr als eine generische Manufacturing-Architektur mit Prozessindustrie-Etikett. Rezeptdaten, SIS-Status und Alarmkontext sind eigenständige Datenobjekte, die die Topic-Struktur von Grund auf mitbestimmen. Das macht Rezeptaudits nach ISA-88, die NOA-Umsetzung und die Alarmrate nach EEMUA 191 praktisch beherrschbar. Drei zentrale Erkenntnisse:
- Branchenspezifische Datenmodellierung: Rezeptdaten, SIS-Status und Alarmkontext sind eigenständige Felder, nicht eine andere Broker-Wahl.
- KI und digitaler Zwilling brauchen Kontext: Ihr Wert entsteht erst durch die Verknüpfung von Prozess-, Alarm- und Qualitätsdaten – und KI ersetzt dabei nie die Laborfreigabe oder eine Sicherheitsfunktion.
- Sicherheitstrennung ist Architekturprinzip, nicht Compliance-Anhängsel: IEC 61511 bestimmt, dass der UNS SIS-Daten nur spiegeln darf – diese Grenze gehört von Anfang an in die Architektur.
Wer diese branchenspezifischen Anforderungen von Beginn an in die Topic-Struktur einbaut, spart sich spätere Umbauten – und ist zugleich vorbereitet, KI- und Digital-Twin-Anwendungsfälle direkt auf einer belastbaren Datenbasis aufzusetzen.
