IT/OT Interoperabilität im Unified Namespace (UNS) – Grundlagen

In modernen Industrie-4.0-Umgebungen wächst der Bedarf, Daten nahtlos zwischen OT (Operational Technology) und IT (Information Technology) auszutauschen. IT/OT Interoperabilität im Unified Namespace (UNS) bezeichnet die Fähigkeit, Maschinendaten und Geschäftssysteme über eine gemeinsame Datenplattform zu verbinden. Ein Unified Namespace fungiert dabei als zentralisiertes, hierarchisches Datenmodell – eine „Single Source of Truth“ für alle IIoT-Daten im Unternehmen. Dadurch können Sensorwerte, Produktionskennzahlen und Geschäftsparameter in Echtzeit von berechtigten Systemen abgerufen und weiterverarbeitet werden. In diesem Artikel erläutern wir die Grundlagen dieser IT/OT-Interoperabilität, von den technischen Ebenen der Datenkommunikation bis hin zu Best Practices für die Umsetzung in einer UNS-Architektur.

Was bedeutet IT/OT Interoperabilität

Unter IT/OT-Interoperabilität versteht man die Fähigkeit, Daten zwischen OT-Systemen – also Maschinen, SPS-Steuerungen, SCADA – und IT-Systemen (z. B. MES, ERP oder Cloud-Plattformen) strukturiert, konsistent und ohne Medienbrüche auszutauschen. Entscheidend ist dabei nicht nur die physische Netzwerkverbindung, sondern vor allem die semantische und syntaktische Verständlichkeit der Daten zwischen beiden Welten. Im Kontext von Industrie 4.0 und Industrial IoT (IIoT) ist diese durchgängige Verständigung unerlässlich, um lückenlose Datenflüsse vom Sensor bis in Analytics-, KI- oder Business-Systeme zu ermöglichen. Ohne einheitliche Standards entstehen sonst nur punktuelle Integrationen, die aufwändig zu pflegen sind und oft zu Vendor-Lock-in führen.

Das Data Access Model – Ebenen der Interoperabilität

Um die Herausforderungen der Interoperabilität greifbar zu machen, lohnt ein Blick auf das Data Access Model nach Matthew Parris. Dieses Rahmenwerk unterteilt die Datenintegration in sechs aufeinander aufbauende Ebenen (Level 0–5), von der reinen Verbindungstechnik bis zur semantischen Beschreibung von Objekten. Jede Ebene definiert einen kritischen Aspekt des Datenzugriffs. Echte „Plug-and-Play“-Interoperabilität ist nur möglich, wenn alle diese Ebenen konsistent zwischen den Systemen abgestimmt sind. Im Folgenden ein Überblick über die sechs Levels.

Level 0 – Transport

Diese unterste Ebene beschreibt die grundlegende Netzwerk- und Transportverbindung zwischen zwei Endpunkten. Hier geht es noch nicht um Inhalte oder Datenformate, sondern ausschließlich um die Übertragungsschicht, die sicherstellt, dass Bits und Bytes zuverlässig von A nach B gelangen. Typische Technologien auf Level 0 sind:

• Allgemeine Netzwerktransporte: z. B. TCP/IP (verbindungsorientiert, garantiert geordnete und vollständige Übertragung) oder UDP (verbindungslos, effizienter, aber ohne Zustellungsgarantie – oft in zeitkritischen OT-Anwendungen genutzt).
• Industrielle Feldbusse/Physiken: z. B. RS-485 oder Lichtwellenleiter als physikalische Basis für Feldbusse wie Profibus.

Beispiel: Eine SPS sendet Prozesswerte via TCP/IP in das Firmennetzwerk. Die IT-Seite sieht zunächst nur IP-Datenpakete – ohne zu wissen, ob darin etwa Temperatur- oder Druckwerte stecken.

Level 1 – Protokoll

Auf dieser Ebene wird definiert, wie die Kommunikation logisch abläuft. Das Protokoll baut auf dem Transport (Level 0) auf und legt fest, wie Nachrichten ausgetauscht werden und welche Kommunikationsregeln gelten. Typische Protokolle sind:

• IT-Standards: HTTP/REST (basiert auf TCP/IP und definiert Methoden wie GET, POST, PUT für den Datenaustausch).
• Offene industrielle Protokolle: PROFINET (Ethernet-basiert mit Erweiterungen für Echtzeit), EtherNet/IP (setzt auf CIP auf, nutzt TCP/UDP), OPC UA (bietet Services wie Read/Write/Subscribe und standardisierte Addressräume), MQTT (leichtgewichtiges Publish/Subscribe-Protokoll auf TCP/IP).
• Vendor-spezifische Protokolle: Beckhoff ADS (für TwinCAT-Steuerungen, auf TCP/UDP aufsetzend) oder Siemens S7-Protokoll über RFC1006 (ISO-on-TCP für S7-SPS).

Beispiel: Eine Maschine publiziert Temperaturwerte per MQTT. Während Level 0 sicherstellt, dass die Pakete ankommen, regelt das MQTT-Protokoll (Level 1), dass diese nach dem Publish/Subscribe-Prinzip über Topics verteilt werden.

Level 2 – Mapping

Diese Ebene bestimmt, wie die Daten innerhalb eines Protokolls adressiert und strukturiert werden. Während das Protokoll (Level 1) den Kommunikationsmechanismus vorgibt, legt das Mapping fest, welche Topics, Pfade oder Adressen zur eindeutigen Kennzeichnung von Daten genutzt werden. Dadurch wird definiert, wo ein bestimmter Wert im Datenstrom zu finden ist. Beispiele:

• IT-Mappings: In RESTful APIs dienen eindeutige URL-Pfade als Mapping (z. B. GET /api/machines/123/telemetrie), um Ressourcen und ihre Datenpunkte eindeutig anzusprechen.
• Offene industrielle Protokolle: PROFINET nutzt Index/Slot-Mechanismen (GSDML-Modelle), EtherNet/IP verwendet CIP-Assembly Instanzen, OPC UA definiert NodeIds als Adressierung, MQTT setzt auf hierarchische Topic-Namen (z. B. factory/line1/machine3/temp), macht jedoch keine Vorgaben zur Struktur der Payload.
• Proprietäre Mappings: Beckhoff ADS adressiert Variablen über IndexGroup/IndexOffset oder symbolische Namen; Siemens S7 nutzt SPS-Datenbaustein-Adressen (DB-Nummer, Byte-/Bit-Offset) zur eindeutigen Identifikation von Variablen.

Beispiel: Eine SPS publiziert den Wert 25,3 °C. Mit plain MQTT könnte dieser Wert im Topic factory/line1/machine3/temp landen – die Payload ist z. B. der String „25.3„. Ohne vorherige Absprache könne Empfänger zwar das Topic auslesen, wissen aber nicht zwangsläufig, ob „25.3“ eine Temperatur in °C, °F oder etwas ganz anderes ist.

Level 3 – Encoding

Level 3 definiert, in welchem Datenformat die Nachricht serialisiert wird. Das Encoding bestimmt also, wie die auf Level 2 definierten Felder als Bytes über den Transport geschickt werden. Die Wahl des Formats beeinflusst Bandbreite, Latenz, CPU-Last und Fehlertoleranz. Gängige Encodings sind:

• Allgemeine Formate: JSON (menschlich lesbar, flexibel, aber größerer Overhead), XML (stark strukturiert via XML-Schema, jedoch verbose und speicherintensiv).
• Industrie-Standards: OPC UA Binary (effizientes binäres Format für OPC UA, neben UA-JSON für Pub/Sub), MQTT-Payloads oft JSON oder kompakte Protocol Buffers (Protobuf) – letzteres ist schemabasiert, binär und sehr performant, erfordert aber ein sorgfältiges Management der Schemas.
• Herstellerformate: Beckhoffs ADS-Telegramm (fester Header inkl. IndexGroup/Offset), Siemens S7-Datentelegramme mit proprietärem Aufbau (Funktionscodes, DB-Adressen, etc.).

Beispiel: Ein OPC UA-Client schickt eine Read-Anfrage für die NodeId ns=2;s=Temperature. Diese Anfrage wird binär codiert. Die Antwort des Servers enthält den Temperaturwert als 32-bit Float – z. B. die Bytefolge 41 80 00 00 (die 16.0 in IEEE 754 repräsentiert).

Level 4 – Values

Ebene 4 legt die Datentypen und Wertebereiche fest, die in einer Nachricht vorkommen dürfen. Nur wenn Sender und Empfänger denselben Datentyp verstehen, kann der Wert korrekt interpretiert werden. Während Level 3 das Wie der Serialisierung vorgibt, bestimmt Level 4 Was für Werte übertragen werden. Unterschiedliche Typkonventionen führen leicht zu Fehlern – z. B. wenn eine Zahl als String gesendet wird, der Empfänger jedoch eine Zahl erwartet. Typische Datentyp-Definitionen:

• Primitive IT-Typen: Boolean, Integer (in verschiedenen Bitbreiten, vorzeichenbehaftet/-los), Float/Double (Fließkommazahlen), String (oft UTF-8).
• Komplexe Typen: Arrays/Listen, Strukturen/Objekte mit verschachtelten Feldern.
• Standardisierte Typen: OPC UA definiert z. B. einen umfangreichen Satz Built-in Datatypes (Boolean, Int16, UInt32, Float, Double, String, DateTime, GUID, etc.) sowie Structured DataTypes für komplexe Strukturen. PROFINET/EtherNetIP haben feste Datentypen für Prozessdaten (Int, Real, Bool …).
• IEC 61131-3-konforme Typen: In SPS-Umgebungen (Beckhoff, Siemens) gelten Standardtypen wie BOOL, INT, DINT, REAL, STRING, ergänzt um vendor-spezifische Formate (bei Siemens z. B. spezielle Zeit- und String-Datentypen).

Beispiel: Eine Maschine meldet den Status „Motor läuft“ als Boolean an ein Leitsystem. Semantik: true, wenn der Motor eingeschaltet ist, und false, wenn er steht. Beide Seiten müssen hierfür übereinstimmen, dass dieser Wert ein Boolean ist und was true/false jeweils bedeuten.

Level 5 – Objects

Die oberste Ebene beschreibt die Organisation der Daten in Objekten und Modellen. Während das Mapping (Level 2) nur festlegt, wo ein einzelner Wert steht, geht es auf der Objektebene darum, wie mehrere Werte logisch zusammengehören und welche Attribute, Eigenschaften oder Methoden sie haben. So entstehen aus isolierten Variablen strukturierte Informationsmodelle, die auch komplexe Maschinen oder Prozesse vollständig abbilden. Beispiele für objektorientierte Datenmodelle:

• OPC UA Companion Specifications: Branchenspezifische Informationsmodelle als Erweiterung von OPC UA (z. B. für Roboter, CNC-Maschinen oder den Weihenstephan-Standard in der Lebensmittelindustrie). Diese definieren standardisierte Objekttypen mit Attributen und Methoden, die von allen Herstellern einheitlich genutzt werden können.
• Asset Administration Shell (AAS): Beschreibt Industrie-Assets als digitale Verwaltungsschale mit standardisierten Submodellen.

Beispiel: Die OPC UA Companion Specification for Robotics definiert ein einheitliches Informationsmodell für Industrieroboter. Ein Roboterarm wird darin als Objekt mit Attributen wie JointPosition, ToolCenterPoint oder OperationMode beschrieben. Egal, ob der Roboter von Hersteller A oder B stammt – über die Companion Specification stellen beide Systeme denselben Objekttyp mit denselben Eigenschaften bereit.

IT/OT Interoperabilität im Unified Namespace (UNS)

Nachdem wir die Ebenen der Interoperabilität betrachtet haben, stellt sich die Frage, wie sich all diese Schichten in der Praxis zusammenführen lassen. Genau hier setzt der Unified Namespace (UNS) an: ein zentrales Datenarchitektur-Konzept, das IT- und OT-Systeme über eine gemeinsame „Drehscheibe“ verbindet. Im Gegensatz zum traditionellen ISA-95-Pyramidenmodell, das Daten strikt nur zwischen separaten Ebenen austauscht, fließen im UNS alle Informationen in einen zentralen Hub. Typischerweise handelt es sich dabei um einen Publish/Subscribe-Bus – meist ein MQTT-Broker –, über den jedes Gerät und jedes System Daten publiziert oder abonniert.

Ein UNS entkoppelt somit Sender und Empfänger vollständig. Systeme sind nicht individuell integriert, sondern lediglich mit dem Broker verbunden. Das erleichtert sowohl das Hinzufügen neuer Datenquellen als auch den Austausch von Verbrauchern, beispielsweise beim Wechsel von MES oder Dashboard-Systemen. Gleichzeitig entsteht durch die zentrale Datenablage ein unternehmensweiter „Single Source of Truth“ für IT und OT. Eine Einführung in das Konzept im Rahmen von Industrie 4.0 finden Sie hier.

Herausforderungen bei der Umsetzung

Für IT/OT-Architekten ist entscheidend zu verstehen, dass kein Protokoll allein alle Ebenen der Interoperabilität abdeckt (Beispiel zu OPC UA und MQTT finden Sie hier). Während MQTT durch Skalierbarkeit und Einfachheit überzeugt, standardisiert es im Sinne des Data Access Models lediglich Transport (Level 0) und Protokoll (Level 1). Alles darüber hinaus – also Mapping, Encoding, Datentypen und Objektmodelle – bleibt offen und muss definiert werden. Wer also nur „MQTT“ als UNS-Vorgabe festlegt, erreicht keine echte Interoperabilität. In der Praxis führt das zu typischen Problemen:

• Uneinheitliche Topics in Level 2: Ohne Vorgaben vergibt jedes System eigene Topic-Namen und Strukturen. Konsumierende Systeme müssen individuell angepasst werden.
• Undefined Payload in Level 3: Ohne Standardisierung wählt jedes Gerät ein eigenes Datenformat – etwa JSON, XML oder Binär. Konsumierende Systeme müssen die Payloads einzeln interpretieren oder transformieren.
• Inkonsistente Datentypen und Semantik in Level 4: Ohne Harmonisierung nutzt jeder Sensor eigene Typen und Einheiten – etwa Temperatur als Float in °C, als Integer oder als String. Konsumierende Systeme laufen Gefahr, Daten falsch zu interpretieren oder Fehler zu erzeugen.
• Kein einheitliches Objektmodell in Level 5: Ohne verbindliche Modelle organisieren Maschinen ihre Daten unterschiedlich – von einfachen Tags bis hin zu komplexen Objektstrukturen. Konsumierende Systeme müssen deshalb für jedes Gerät spezifische Integrationslogik entwickeln, um die Daten in ein einheitliches Modell zu überführen.

Fehlen hierfür verbindliche Spezifikationen, entwickeln Teams häufig proprietäre Integrationen, die nur für den jeweiligen Anwendungsfall optimiert sind. Diese Lösungen wirken kurzfristig effektiv, erzeugen aber langfristig keine Interoperabilität und führt in Folge zu Integrationsaufwand.

Strategien in der Praxis und ihre Grenzen

Mangels eines durchgängigen Industriestandards über alle Ebenen hinweg haben sich verschiedene Strategien etabliert. Jede bringt Vorteile, aber auch klare Grenzen mit sich:

1. Use-Case-spezifische Strategie: Für einzelne Projekte oder Piloten werden ad-hoc Vorgaben definiert.
   • Vorteil: Schnelle Umsetzung, geringe Anfangshürde.
   • Nachteil: Keine Wiederverwendbarkeit – im Laufe der Zeit entsteht ein Flickenteppich von Insellösungen.
2. Unternehmens-spezifische Strategie: Firmen entwickeln interne Konventionen für Topic-Namen, Payload-Formate und Datentypen.
   • Vorteil: einheitliche Kommunikation im Unternehmen.
   • Nachteil: Interoperabilität über Unternehmensgrenzen hinweg ist nicht gegeben. Hoher Aufwand für Anforderungsanalyse im gesamten Unternehmen bedarf entsprechende Ressourcen.
3. Offene Standards: Initiativen wie Sparkplug B oder OPC UA Companion Specifications standardisieren weitere Ebenen.
   • Vorteil: Übergreifende Interoperabilität auf der jeweiligen Ebene, sofern alle Beteiligten die Standards umsetzen.
   • Nachteil: Oft nur begrenzt verbreitet; das Einsatzszenario muss sorgfältig geprüft werden. Beispiel: Sparkplug B eignet sich primär für SCADA-Umgebungen.

Best Practices

Damit ein UNS tatsächlich Interoperabilität schafft, benötigen Unternehmen ein verbindliches Regelwerk, das für alle Publisher und Subscriber gilt. Dieses Regelwerk sollte jede Interoperabilitätsebene im Sinne des Data Access Models klar definieren. Dabei helfen zwei grundlegende Prinzipien:

1. An offenen Standards orientieren: Nutzen Sie etablierte Modelle wie ISA-95 oder OPC UA Companion Specifications als Referenz und passen Sie diese an die eigenen Anforderungen an – etwa durch konsistente Benennungsregeln für UNS-Parameter.
2. Optionen minimieren: Beschränken Sie die Vielfalt pro Ebene auf das unbedingt Notwendige, um die Komplexität zu minimieren. Beispiel: JSON als Standardformat, ergänzt durch Protobuf für Szenarien mit hohen Bandbreiten- oder Performance-Anforderungen.

Konkrete Empfehlungen pro Ebene:

• Level 2 – Topic-Struktur (Mapping): Definieren Sie eine konsistente, hierarchische Namenskonvention, z. B. angelehnt an ISA-95 (Standort / Bereich / Linie / Maschine / Signal). Das erleichtert die Orientierung im Namespace und verhindert Wildwuchs. Detaillierte Best Practices finden Sie hier.
• Level 3 – Encoding: Legen Sie ein Standard-Payload-Format fest – in den meisten Fällen JSON. Für bandbreitenkritische Szenarien kann zusätzlich ein Binärformat wie Protocol Buffers parallel im Namespace existieren. Weitere Infos finden Sie hier.
• Level 4 – Datentypen: Harmonisieren Sie die Datentypen für Messwerte, Zählerstände und Statusmeldungen. Beschränken Sie sich dabei auf das Minimum der Anforderungen.
• Level 5 – Objektmodelle: Nutzen Sie, wo möglich, bestehende Informationsmodelle (z. B. OPC UA Companion Specifications wie den Weihenstephan-Standard) und adaptieren Sie diese, wo es erforderlich ist.

Neben technischen Vorgaben sind organisatorische Regeln entscheidend: Wer darf neue Topics oder Datenpunkte definieren? Wie läuft das Änderungsmanagement ab? Welche Security-Best-Practices gelten? Dazu gehören Authentifizierung und Autorisierung am Broker, Netzwerksegmentierung zwischen IT und OT sowie Monitoring des Datenverkehrs.

Fazit

Die IT/OT Interoperabilität im Unified Namespace ist ein Schlüsselkonzept für zukunftsfähige Industrie-Architekturen. Durch einen UNS lassen sich die ehemals starren Schichten der Automation in einen flexiblen, ereignisgetriebenen Datenraum überführen, der alle Beteiligten – von der Sensorsteuerung bis zur Cloud-Analytics – in Echtzeit verbindet. Entscheidend ist jedoch, über die reinen Connectivity-Fragen hinauszudenken: Erst wenn auf allen Ebenen – von Transport über Protokoll bis zur Datensemantik – gemeinsame Standards gelten, entfaltet ein UNS sein volles Potenzial. Unternehmen sollten daher frühzeitig in die Definition solcher Standards investieren und wo möglich auf offene, etablierte Modelle zurückgreifen, um Insellösungen zu vermeiden.

Für OT/IT-Architekten bedeutet dies, sowohl die technologischen Grundlagen (Netzwerk, Protokolle, Formate) als auch die Informationsmodellierung zu beherrschen. Gelingt dies, entsteht eine durchgängige Dateninfrastruktur, in der neue Maschinen, Anwendungen oder Analysesysteme plug-and-play integriert werden können. Die Mühe der Standardisierung zahlt sich langfristig in agileren Integrationsprojekten, geringerem Engineering-Aufwand und höherer Datenqualität aus.