Manufacturing Data Architecture

In vielen Industrieunternehmen sind Produktionsdaten technisch vorhanden – in PLCs, SCADA-Systemen, Historian, MES oder einzelnen Dashboards. Trotzdem bleiben Entscheidungen fragmentiert, reaktiv oder schwer skalierbar.

Der Grund liegt fast nie in fehlenden Tools. Er liegt in einer fehlenden oder ungeeigneten Datenarchitektur.

Bei Substring arbeiten wir deshalb mit einer klaren Referenzarchitektur, die wir in jedem Industrieprojekt als Ausgangspunkt nutzen. Sie beschreibt, wie industrielle Daten vom Sensor bis zur Entscheidung strukturiert aufgebaut werden – so, dass sie betrieblich stabil bleiben, fachlich interpretierbar sind und über einzelne Use Cases hinaus skalieren.

Dieser Artikel beschreibt die Architektur, ihre Ebenen und die Denklogik dahinter.

Zwei Dimensionen, nicht eine Pipeline

Die meisten Architekturdarstellungen zeigen Daten als lineare Kette: Maschine → Broker → Datenbank → Dashboard. Das ist verführerisch einfach – und gleichzeitig der Ursprung vieler Probleme: vermischte Verantwortlichkeiten, unklare Semantik, schwer erweiterbare Systeme.

Unsere Referenzarchitektur trennt deshalb bewusst zwei Dimensionen.

Dimension 1 – Datenfluss (vertikal)

Wie kommen Daten von der Maschine in nutzbare Systeme, und wo werden sie gespeichert? Der Datenfluss beschreibt den Weg von den Quellen über Konnektivität, Übersetzung und Messaging hin zu Historian, Data Lake und schliesslich zur Nutzung.

Dimension 2 – Struktur und Semantik (querliegend)

Was bedeuten diese Daten – unabhängig davon, wo sie gerade liegen? Unified Namespace, Asset Model, Payload-Definition und Naming-Konventionen bilden ein Querprinzip, das sich durch alle Ebenen zieht. Es sorgt dafür, dass Daten jederzeit verständlich, rückverfolgbar und erweiterbar bleiben.

Diese Trennung ist kein akademisches Konstrukt. Sie ist der Grund, warum manche Architekturen beim dritten Use Case skalieren – und andere beim dritten Use Case zusammenbrechen.

In den folgenden Abschnitten beschreiben wir beide Dimensionen im Detail.

Datenfluss: Von der Maschine zur Nutzung

Data Sources – Ursprung der Produktionsdaten

Am Anfang jeder Manufacturing Data Architecture stehen die Datenquellen im Shopfloor: PLCs und Steuerungen, Sensoren und Aktoren, Tags, Zähler, Alarme und Zustände, SCADA- und Leitsysteme, MES und BDE-Systeme sowie manuelle Eingaben wie Stillstandsgründe oder Schichtnotizen.

Diese Daten sind hochfrequent, zeitkritisch und stark maschinennah. Sie enthalten in der Regel wenig Semantik und sind nicht direkt für Analytics, Planung oder Integration geeignet.

In vielen Projekten sehen wir, dass genau hier der erste Fehler passiert: Rohe Maschinendaten werden direkt in ein Dashboard gezogen – ohne Kontext, ohne Modell, ohne Struktur. Das funktioniert für einen einzelnen Use Case, aber es skaliert nicht.

Maschinenkonnektivität – strukturierter Zugriff auf die OT-Welt

Der erste Schritt in der Architektur ist der standardisierte Zugriff auf Maschinen und Anlagen. Dieser Layer ist maschinennah und liest Daten aus Steuerungen, Sensoren und operativen Systemen.

Typische Protokolle in diesem Bereich sind OPC UA, Modbus TCP, PROFINET, EtherNet/IP, MTConnect oder S7. OPC UA hat sich als De-facto-Standard etabliert, weil es nicht nur Daten transportiert, sondern auch strukturierte Modelle für Maschinen und Assets mitbringt. Je nach Maschinenpark und Bestandslandschaft kommen jedoch oft mehrere Protokolle parallel zum Einsatz.

Entscheidend ist: Dieser Layer liefert strukturierten Zugriff auf Rohdaten. Die Daten sind auf dieser Ebene noch nicht kontextualisiert und noch nicht entkoppelt.

Übersetzung und Kontextualisierung – wo Bedeutung entsteht

Zwischen Maschinenkonnektivität und Messaging liegt der Layer, der in vielen Architekturen fehlt oder unterschätzt wird – und der in unserer Erfahrung den grössten Unterschied macht: die Übersetzung und Kontextualisierung.

Hier werden rohe Tags fachlichen Assets zugeordnet, technische Signale in verständliche Events übersetzt, mehrere Einzelsignale zu fachlichen Aussagen zusammengeführt und Payloads mit Metadaten angereichert – Linie, Maschine, Prozessschritt, Einheit, Auftrag.

Wichtig ist, dass es hier nicht nur um Maschinen und Assets geht, sondern gleichermassen um Prozesse und Abläufe: Prozessschritte abbilden, Auftrags- und Schichtkontext herstellen, Qualitäts- und Rezeptdaten einordnen.

Dieser Layer wird typischerweise durch eine Industrial DataOps Platform umgesetzt. Entscheidend ist nicht das spezifische Tool, sondern die architektonische Funktion: Daten werden verständlich, konsistent und interpretierbar gemacht, bevor sie weiterverteilt werden.

Das ist der einzige Punkt in der Architektur, an dem aus Daten erstmals Information wird. In jedem Projekt, das wir bei Substring umsetzen, investieren wir hier bewusst Zeit – weil die Qualität dieses Layers über den Wert aller nachgelagerten Systeme entscheidet.

MQTT Broker – Messaging und Verteilung via UNS Topics

Nach der Kontextualisierung werden die Daten über einen MQTT Broker entkoppelt und asynchron an alle Konsumenten verteilt.

Die Topic-Struktur des Brokers folgt dabei dem Unified Namespace: Standort, Linie, Maschine, Signal. Dadurch entsteht eine klare, hierarchische Adressierung, die für alle nachgelagerten Systeme einheitlich lesbar ist.

MQTT übernimmt die skalierbare, ereignisgetriebene Verteilung kontextualisierter Daten. Es beliefert nicht ein einzelnes Zielsystem, sondern alle Konsumenten gleichzeitig – Historian, Data Lake, Dashboards, Alerting oder externe Systeme.

Historian und Data Lake – zwei parallele Konsumenten

An dieser Stelle teilt sich der Datenfluss. Historian und Data Lake sind nicht sequenziell angeordnet, sondern parallele Konsumenten des MQTT Brokers. Beide empfangen Daten direkt – und haben unterschiedliche Aufgaben.

Historian und Time-Series Databases sichern die zeitliche Wahrheit. Sie speichern hochfrequente Zeitreihen mit sauberen Zeitachsen und Zustandsmodellen. Ihre Stärke ist die reproduzierbare Speicherung von Prozessdaten über beliebige Zeiträume. Der Historian ist weder Data Lake noch Analytics-Plattform. Er ist die zeitliche Referenzschicht der Architektur.

Der Data Lake bildet die zentrale Integrations- und Erweiterungsbasis für analytische Nutzung. Er folgt typischerweise dem Medaillon-Prinzip:

• Bronze enthält Rohdaten: Time-Series, Events und UNS-Rohdaten – vollständig, unverändert und nachvollziehbar.
• Silver enthält modellierte Daten: Digital Twin, Prozessmodelle und Asset-Hierarchien – bereinigt, harmonisiert und verknüpft.
• Gold enthält entscheidungsfähige Daten: Produktions-KPIs und auswertbare Datenmodelle – direkt nutzbar für Dashboards, Reports und Modelle.

Historian-Daten können zusätzlich in den Bronze-Layer des Data Lake fliessen. Die beiden Systeme ergänzen sich, sie ersetzen sich nicht.

Nutzung – von Dashboards bis Predictive Maintenance

Erst auf Basis der vorherigen Ebenen entstehen belastbare Nutzungsszenarien: Shopfloor-Dashboards und Management-Reports, OEE- und Stillstandsanalysen, Qualitäts- und Energieanalysen, Ursachen- und Engpassanalysen, Optimierungsmodelle, Predictive Maintenance, Machine Learning und Supply-Chain-Integration.

Die Qualität jedes einzelnen dieser Use Cases hängt direkt von der Klarheit der darunterliegenden Architektur ab. Nicht vom BI-Tool, nicht von der Cloud-Plattform, sondern von der Struktur darunter.

Struktur und Semantik: Das Querprinzip

Es gibt eine Dimension in dieser Architektur, die nicht im Datenfluss liegt, sondern ihn durchzieht. In der Referenzgrafik ist sie bewusst als vertikale Spalte neben dem Datenfluss dargestellt – weil sie auf jeder Ebene gleichermassen wirkt.

Unified Namespace (UNS)

Der Unified Namespace bildet die logische Struktur der Produktionsrealität ab. Er beschreibt, welche Assets existieren, wie sie hierarchisch organisiert sind und wie Daten logisch zusammengehören.

In unseren Projekten definieren wir den UNS gemeinsam mit dem Kunden als erstes architektonisches Artefakt – noch bevor wir über Tools, Datenpipelines oder Dashboards sprechen. Denn der UNS bestimmt, wie skalierbar die gesamte Architektur sein wird.

Asset Model

Das Asset Model definiert die Beziehungen zwischen physischen Einheiten: Werk, Linie, Maschine, Station. Es stellt sicher, dass jeder Datensatz eindeutig einem Asset zugeordnet werden kann – unabhängig davon, ob er im Historian, im Data Lake oder in einem Dashboard landet.

Payload-Definition

Die Payload-Definition regelt, welche Kontextinformationen ein Datensatz mitbringen muss, um korrekt interpretiert zu werden. Ziel ist, dass jeder Datensatz für sich allein verständlich ist – mit klaren Feldnamen, Einheiten, Zeitstempeln und Kontextfeldern.

Ohne saubere Payload-Definition entstehen Datensätze, die nur im Originalsystem lesbar sind und bei jeder Weiterverwendung manuell nachinterpretiert werden müssen.

Naming und Traceability

Einheitliche Benennung und lückenlose Rückverfolgbarkeit sorgen dafür, dass neue Maschinen, Linien oder Standorte nahtlos integriert werden können – ohne bestehende Use Cases neu verdrahten zu müssen.

Zusammen bilden UNS, Asset Model, Payload-Definition und Naming die semantische Klammer der gesamten Architektur. Sie sind kein separater Implementierungsschritt, sondern ein Prinzip, das von Anfang an mitgedacht und in jede Ebene eingebettet wird.

Warum diese Architektur funktioniert

Viele Industrieunternehmen starten mit einem Dashboard, das auf einen einzelnen Use Case zugeschnitten ist. Das erste Ergebnis sieht gut aus. Beim zweiten oder dritten Use Case beginnen die Probleme: steigender Integrationsaufwand, widersprüchliche KPIs, fehlende Vergleichbarkeit über Maschinen oder Linien hinweg, sinkende Akzeptanz bei Anwendern.

Fast immer liegt der Grund in einer Architektur, die Transport, Bedeutung und Speicherung vermischt hat – oder in der Semantik nur als Nachgedanke behandelt wurde.

Die hier beschriebene Referenzarchitektur vermeidet genau das, indem sie klare Verantwortlichkeiten pro Ebene definiert, Semantik als durchgängiges Querprinzip behandelt und jede Ebene unabhängig erweiterbar hält.

In der Praxis bedeutet das: Der erste Use Case kostet Aufbauarbeit. Aber jeder weitere Use Case wird schneller, günstiger und konsistenter – weil die Architektur dafür gemacht ist.

Unser Standardvorgehen

Bei Substring ist diese Referenzarchitektur kein theoretisches Modell. Sie ist unser Standardvorgehen für industrielle Datenarchitekturen.

In jedem Projekt beginnen wir mit der gleichen Frage: Welche Entscheidungen sollen die Daten ermöglichen? Daraus leiten wir gemeinsam mit dem Kunden die relevanten Signale, das Datenmodell und die passende Architektur ab – entlang der hier beschriebenen Ebenen. Oft starten wir mit einer Datenlandkarte, um die bestehende Systemlandschaft zu verstehen.

Wir definieren den Unified Namespace und das Asset Model als erstes strukturelles Fundament. Wir investieren bewusst in die Kontextualisierungsebene, weil sie den grössten Hebel auf die Qualität aller nachfolgenden Use Cases hat. Und wir bauen die Architektur so, dass sie iterativ wachsen kann – Use Case für Use Case, Linie für Linie, Werk für Werk.

In der Praxis zeigt sich der Wert dieser Architektur besonders in konkreten Projekten – etwa bei der Predictive-Maintenance-Lösung für die Sortieranlagen der Post, wo saubere Datenstrukturen die Grundlage für zuverlässige KI-Modelle bilden.

Wie dieses Vorgehen im Detail aussieht, beschreiben wir in unserem Shopfloor-to-Insight Framework.

Fazit

Manufacturing Data Architecture ist kein Analytics-Projekt und kein Tool-Entscheid. Sie ist die strukturelle Grundlage dafür, dass industrielle Daten integriert, verständlich und skalierbar nutzbar werden.

Wer mit Dashboards beginnt, optimiert Symptome. Wer mit einer sauberen Architektur beginnt, schafft langfristige Handlungsfähigkeit.

Sie möchten wissen, wie eine solche Architektur für Ihr Unternehmen aussehen könnte? Sprechen Sie mit uns.

‍