Unified Namespace (UNS): Erst das Problem verstehen, dann über MQTT reden.

WISSEN | INDUSTRIAL DATA

Ein Unified Namespace macht Produktionsdaten über Maschinen, Linien und Werke hinweg einheitlich verfügbar.

Was ein Unified Namespace wirklich ist, welches Problem er löst und wann er sinnvoll eingesetzt werden sollte erkläre ich hier praxsinah.
Technologie ist allerdings kein Selbstzweck und noch wichtig: ein MQTT Broker allein ist noch kein UNS.

Von Martin Waßmann – IT/OT Experts

Was ist ein Unified Namespace?

Unified Namespace ist inzwischen eines dieser Themen, bei denen sehr schnell über MQTT, Broker und Topics gesprochen wird.
Dabei beginnt das eigentliche Problem meistens viel früher.

Eine Maschine liefert Daten für KPIs, häufig OEE. Dann braucht ein Reporting dieselben Informationen. Später kommt Traceability dazu, vielleicht noch Energie-Monitoring, Analytics oder auch KI. Jede Anwendung wird irgendwie angebunden und irgendwann hat man viele funktionierende Lösungen, aber keine skalierbare Datenarchitektur – Wartbarkeit noch ein zusätzliches Thema. Im schlechtesten Fall hat man eine unsichere Verbindung zwischen IT und OT geschaffen.Genau an dieser Stelle kann ein Unified Namespace sinnvoll werden.
Nicht, weil MQTT grad in ist. Nicht, weil zwischen OT und IT plötzlich ein Broker steht. Sondern weil Produktionsinformationen einmal strukturiert, mit Kontext versehen und für unterschiedliche Anwendungen bereitgestellt werden.

Definition: Ein Unified Namespace (UNS) ist eine gemeinsame, strukturierte Datenebene für industrielle Informationen.

Maschinen, Anlagen und Systeme stellen relevante Informationen so bereit, dass andere Anwendungen sie eindeutig verstehen und nutzen können. Nicht nur technisch, sondern auch fachlich.
Es geht also nicht lediglich darum, einen Wert von A nach B zu transportieren.
Eine Anwendung soll nicht nur wissen:

DB17.DBX4.2 = 1

sondern beispielsweise:

Werk → Linie → Verpackungsmaschine → Betriebszustand = Produktion

Der Unterschied klingt banal. In der Praxis entscheidet genau dieser Kontext darüber, ob sich eine Datenarchitektur später skalieren lässt.
Ein UNS ist deshalb kein einzelnes Produkt, das man installiert. Er ist ein Architektur- und Informationskonzept.

Der eigentliche Wert entsteht deshalb nicht dadurch, dass Daten „zentral liegen“. Entscheidend ist, dass unterschiedliche Systeme dieselbe Bedeutung derselben Information verstehen.

Ein UNS ist damit weniger ein einzelnes Produkt als ein Architektur- und Informationskonzept.

Welches Problem löst ein UNS?

In den meisten Unternehmen mangelt es nicht an Daten. Das Problem ist eher:

• sie liegen in unterschiedlichen Systemen,
• heißen an jeder Maschine anders,
• haben keinen einheitlichen Kontext,
• werden für jeden neuen Use Case erneut angebunden,
• und oft weiß niemand mehr genau, welche Anwendung woher welche Information bekommt.

Und irgendwie funktioniert dies auch erstaunlich gut – für eine gewisse Zeit.

Eine Maschine, eine Anwendung – kein Problem. Zehn Maschinen, drei Cases, irgndwie beherrschbar. Aber es kommt der Punkt, da werden es mehr und mehr Linien, mehrere Werke und eine Vielzahl an Anwendungen. Damit wächst die Anzahl der Abhängigkeiten.
Eine kleine Änderung an einer Anlage sorgt dann für ein Chaos in x-Anwendungen und die Integrationsarbeit beginnt von vorn.
Das ist der Punkt, an dem die Architektur zum Problem wird.

Ein Unified Namespace versucht genau dieses Problem zu lösen: Produktionsinformationen werden einmal in einen gemeinsamen Kontext gebracht und anschließend für mehrere Anwendungen nutzbar gemacht.

Wie funktioniert ein Unified Namespace?

Die grundlegende Idee ist simpel: Produktionsinformationen werden nicht für jede Anwendung separat bereitgestellt. Stattdessen werden relevante Informationen einmal aus Maschinen und Systemen geholt, in einen gemeinsamen Kontext gebracht und anschließend für unterschiedliche Anwendungen verfügbar gemacht.
Maschinendaten können beispielsweise über OPC UA, Modbus oder herstellerspezifische, proprietäre, Schnittstellen erfasst werden. Anschließend werden relevante Informationen in eine definierte Struktur überführt und über den Unified Namespace bereitgestellt.

Eine solche Struktur kann sich beispielsweise an Standort, Produktionsbereich, Linie, Anlage und Funktion orientieren. (ISA-95)

Statt einer typischen Information, wie “DB17.DBX2.1” soll eine Anwendung die Information “Werk -> Linie -> Verpackungsmaschine1 -> Zustand” verstehen.

So wird aus einem Datenpunkt eine technische Information mit Kontext.
Es verschiebt sich von “Wie bekommt eine Anwendung X Daten aus Maschine Z” hin zu “Welche Information stellt Maschine Z bereit und welche Anwendungen benötigen diese Information?”. Für die Skalierung ein enorm wichtiger Unterschied.

Warum taucht MQTT dabei ständig auf?

MQTT ist ein quellenoffenes, ereignisorientiertes, Publish / Subscribe Protokoll, welches einem ISO Standard (ISO IEC 20922) genügt. Soviel zur Theorie.

MQTT eignet sich sehr gut für solche Architekturen, weil Daten nicht klassisch von einer Anwendung abgefragt werden müssen.
Ein System veröffentlicht eine Information. Andere Systeme, die diese Information benötigen, abonnieren sie.
Das reduziert direkte Abhängigkeiten zwischen Datenquelle und Anwendung.

Aber:
MQTT löst nur den Transport. Von Haus aus lässt es Freiheit bei der Struktur.

Wenn ich sämtliche SPS-Tags unverändert auf einen MQTT-Broker schreibe, habe ich zwar MQTT eingeführt – aber noch keinen Unified Namespace. Im Zweifel habe ich dann nur mein bestehendes Datenchaos schneller verteilt. Glückwunsch.

Für einen funktionierenden UNS braucht es zusätzlich unter anderem:

• eine nachvollziehbare Struktur,
• eindeutige Bezeichnungen,
• Kontext,
• Regeln für Änderungen,
• und Klarheit darüber, wer für welche Informationen verantwortlich ist.

→ Wie MQTT, OPC UA und UNS genau zusammenspielen, ist ein eigenes Thema. Das behandeln wir hier separat.

Wer braucht einen Unified Namespace? Wem nützt es?

Nicht jedes Unternehmen benötigt einen Unified Namespace.

Wenn eine einzelne Maschine Daten an eine einzelne Anwendung liefern soll, kann eine direkte Verbindung die beste Lösung sein.
Auch wenn bestehende Systeme den benötigten Informationsfluss bereits sauber und skalierbar abdecken, muss man nicht zusätzlich eine neue Architektur einziehen.
Ein UNS wird besonders interessant, wenn:

• mehrere Anwendungen dieselben Produktionsdaten benötigen,
• viele unterschiedliche Maschinen integriert werden sollen,
• mehrere Werke auf eine gemeinsame Datenstruktur gebracht werden sollen,
• immer wieder dieselben Integrationen entstehen,
• oder neue Use Cases regelmäßig neue Punkt-zu-Punkt-Verbindungen verursachen würden.

Dann lohnt es sich, nicht nur über die nächste Schnittstelle nachzudenken, sondern über die gemeinsame Datenarchitektur dahinter.

Und was wird durch einen Unified Namespace ersetzt?

Auch hier: weniger als manchmal suggeriert wird.
Ein Unified Namespace ersetzt nicht plötzlich MES, ERP, Historian oder andere Produktionssysteme.
Diese Systeme haben eigene Aufgaben.
Der UNS kann aber dafür sorgen, dass sie nicht jedes Mal ihre eigene Verbindung zu denselben Datenquellen bauen müssen.
Darin liegt der wesentliche Unterschied.

Ich würde einen UNS deshalb nicht als neue zentrale Superplattform betrachten, die alles andere ablöst.
Man muss sich die Frage stellen, welche Aufgaben ein jedes System erfüllt und welches Problem diese Systeme lösen.

Berechne ich nur die Produktions-KPIs mit einem MES, und nutze es überhaupt nicht für Themen, für die es eigentlich gebaut wurde, dann sollte ich überlegen ob ich diese KPIs nicht quellennah in einem Service beim UNS berechnen lasse.

→ UNS vs. MES und Historian: Was ersetzt hier eigentlich was?

Brownfield? Ja, bitte!

In Bestandswerken sieht die Realität oft anders aus, als im Greenfield. Maschinen unterschiedlichster Hersteller und Generationen. Manche liefern OPC UA, andere Modbus. Datenmodelle? Ist das etwas zu Essen?…

Hier wird der Einsatz eines UNS plötzlich sehr interessant.
Hintergrund ist, dass man die Unterschiede der Maschinen nicht in Anwendungen weiterreicht. Man löst diese Abhängigkeit quellennah. Die Information, die im UNS bereitgestellt wird ist standardisiert und nicht mehr maschinenspezifisch.

→ Link zu den Cases

Was geht schief? Wo liegen häufige Denkfehler?

Viele UNS-Projekte starten technisch: Welchen Broker nehmen wir? Das ist viel zu früh.
Vorher sollten andere Fragen beantwortet werden:

• Welche Informationen benötigen wir überhaupt, um das Problem zu lösen?
• Für welche Use Cases?
• Welche Systeme sind dafür die Quelle?
• Wie soll eine Maschine oder Anlage eindeutig beschrieben werden?
• Wer entscheidet über Struktur und Benennung?
• Was passiert, wenn später ein zweites oder fünftes Werk dazukommt?

Wenn diese Fragen ungeklärt bleiben, kann auch der beste Broker daraus keine saubere Datenarchitektur machen.
Oder anders gesagt:

Ein UNS scheitert selten daran, dass MQTT nicht funktioniert. Er scheitert eher daran, dass niemand festgelegt hat, was die Daten eigentlich bedeuten sollen.

Häufige Fragen

Ist MQTT dasselbe wie ein Unified Namespace?

Nein. MQTT ist ein Kommunikationsprotokoll. Ein Unified Namespace beschreibt darüber hinaus, wie industrielle Informationen strukturiert, kontextualisiert und für unterschiedliche Systeme bereitgestellt werden.

Braucht ein UNS zwingend MQTT?

Nicht grundsätzlich. MQTT eignet sich durch sein Publish/Subscribe-Prinzip allerdings sehr gut für UNS-Architekturen und wird deshalb häufig eingesetzt.

Ersetzt ein UNS ein MES?

Nein. Ein MES unterstützt operative Produktionsprozesse. Ein UNS stellt Informationen für unterschiedliche Systeme bereit. Beide können sich sinnvoll ergänzen.

Funktioniert ein UNS auch im Brownfield?

Ja. Gerade dort kann eine gemeinsame Informationsstruktur sinnvoll sein, weil Maschinen und Steuerungen sehr unterschiedliche Schnittstellen und Datenmodelle besitzen.

Ist ein UNS nur etwas für Konzerne?

Nein. Entscheidend ist nicht die Unternehmensgröße. Entscheidend ist, wie viele Datenquellen, Anwendungen und Integrationen zusammenkommen und ob diese Struktur zukünftig skalieren muss.

Sie diskutieren gerade über UNS, MQTT oder eine neue Produktionsdatenplattform?
Bevor Technologie ausgewählt wird, sollte klar sein, welches Problem die Architektur eigentlich lösen soll. Genau dort setzen wir an.

Über den Autor

Martin Waßmann ist Gründer von IT/OT Experts und unterstützt produzierende Unternehmen bei Digitalstrategie, IT/OT-Integration und skalierbaren Produktionsdatenarchitekturen. Schwerpunkte sind unter anderem Brownfield-Integration, Unified Namespace, MQTT und OPC UA.

Mehr über Martin Waßmann