ERP-System mit Unified Namespace verbinden

Wer die Diskussionen rund um den Unified Namespace verfolgt, dem fällt eines auf: Der Fokus liegt fast ausschliesslich auf Maschinen. SPSen, Sensoren und SCADA-Systeme an einen MQTT-Broker anzubinden ist vergleichsweise einfach. Es gibt etablierte Protokolle, fertige Konnektoren und ein wachsendes Ökosystem von Edge-Geräten, die genau dafür entwickelt wurden.

Aber der eigentliche Wert eines Unified Namespace entsteht erst, wenn Shopfloor-Daten auf Geschäftskontext treffen. Und dieser Kontext lebt in deinem ERP-System.

Die Maschine sagt dir, dass in der letzten Stunde 47 Teile vom Band gelaufen sind. Aber für welchen Fertigungsauftrag sind diese Teile? Welcher Kunde wartet darauf? Liegt ihr vor oder hinter dem Zeitplan? Entspricht die Qualität den Anforderungen dieses spezifischen Kunden?

Diese Fragen lassen sich nur beantworten, wenn Maschinenereignisse mit ERP-Daten verknüpft werden. Und genau diese Verbindung zu bauen — was wir die ERP-UNS-Brücke nennen — ist der Punkt, an dem die meisten Unternehmen stecken bleiben.

Warum das schwieriger ist als gedacht

Maschinen an einen UNS anzubinden ist relativ fehlerverzeihend. Ein Sensor sendet jede Sekunde Temperaturwerte. Wenn eine Nachricht verloren geht, kommt einen Moment später die nächste. Die Daten sind von Natur aus redundant.

ERP-Systeme sind anders. Sie verwalten transaktionale Daten — diskrete Geschäftsereignisse, die den Zustand dauerhaft verändern. Wenn ein Fertigungsauftrag freigegeben oder ein Kundenauftrag bestätigt wird, ist das kein kontinuierlicher Datenstrom. Es ist ein einzelnes, kritisches Ereignis, das korrekt erfasst werden muss.

Dieser fundamentale Unterschied schafft drei Herausforderungen:

1. Unterschiedliche Datenrhythmen. Maschinen erzeugen kontinuierliche Ströme. ERP-Systeme arbeiten in Transaktionen. Beides zu mischen erfordert sorgfältiges Design.

2. Autorität und Datenhoheit. Dein ERP-System ist die „Single Source of Truth" für Geschäftsdaten. Jede Integration muss diese Autorität respektieren, ohne sie versehentlich zu korrumpieren.

3. Semantische Diskrepanz. Maschinen sprechen in physikalischen Einheiten — Temperaturen, Drücke, Zyklen. ERP-Systeme sprechen in Geschäftsabstraktionen — Aufträge, Arbeitsgänge, Arbeitspläne, Arbeitsplätze. Die Übersetzung zwischen diesen Welten erfordert explizites Mapping.

Das Brückenmuster: Als Beobachter starten, zum Teilnehmer werden

Beim Aufbau einer ERP-UNS-Integration empfehlen wir, mit einem schreibgeschützten Ansatz zu beginnen: Erst beobachten, dann teilnehmen.

Dein ERP-System verwaltet die Produktion seit Jahren. Es kümmert sich um Kalkulation, Lagerbestand, Kapazitätsplanung und Finanzberichte. Das sind komplexe, miteinander verflochtene Prozesse, die über die Zeit verfeinert wurden. Direkt in automatisierte Buchungen einzusteigen, ohne die Datenqualität und Randfälle zu verstehen, ist riskant.

Das Brückenmuster startet aus ERP-Sicht strikt schreibgeschützt. Es beobachtet, was in beiden Systemen passiert, und schafft eine einheitliche Sicht. Das ermöglicht dir, die Datenqualität zu validieren, Vertrauen aufzubauen und Randfälle zu verstehen, bevor du automatisierte Transaktionen aktivierst.

Sobald du festgestellt hast, dass die Ausführungsdaten zuverlässig sind, wird der nächste Schritt möglich: Shopfloor-Fakten für ERP-Buchungen nutzen. Von Maschinen gemeldete Istmengen können Verbrauchsbuchungen auslösen. Zykluszeiten können in genauere Kalkulationen einfliessen. Stillstandsereignisse können die Kapazitätsverfügbarkeit aktualisieren.

Diese Progression — vom Beobachter zum Teilnehmer — ist beabsichtigt. Sie bedeutet, dass du eine UNS-Integration ausrollen, ihren Wert beweisen und dann ihre Autorität schrittweise erweitern kannst, während das Vertrauen wächst.

Das Brückenmuster: Maschinen publizieren in den UNS, die Brücke reichert mit ERP-Kontext an

Was durch die Brücke fliesst

Um die Brücke zu verstehen, verfolgen wir, was passiert, wenn eine Maschine ein Teil produziert.

Schritt 1: Die Maschine publiziert ein Ereignis

{
    "topic": "factory/lineA/cell1/cnc-mill",
    "payload": {
        "cycleComplete": true,
        "partCount": 1,
        "cycleTime": 42.3,
        "timestamp": "2025-01-27T14:32:15Z"
    }
}

Zu diesem Zeitpunkt hat die Nachricht keinen Geschäftskontext. Es ist nur eine Maschine, die sagt: „Ich habe einen Zyklus abgeschlossen."

Schritt 2: Die Brücke fügt Kontext hinzu

Die Brücke abonniert Maschinen-Topics. Wenn sie dieses Ereignis sieht, schlägt sie den aktuellen Fertigungsauftrag nach, der auf diesem Arbeitsplatz läuft. Sie konsultiert ihre Mapping-Tabelle, um das UNS-Topic (factory/lineA/cell1/cnc-mill) in einen ERP-Arbeitsplatzcode (WC-CNC-01) zu übersetzen.

Dann fragt sie die ERP-API: „Welcher Fertigungsauftrag läuft gerade auf Arbeitsplatz WC-CNC-01?"

Schritt 3: Die Brücke erstellt ein verankertes Ausführungsereignis

{
    "messageId": "550e8400-e29b-41d4-a716-446655440000",
    "orderNo": "FA-12345",
    "operationNo": "20",
    "workCenter": "WC-CNC-01",
    "qtyProduced": 1,
    "cycleTimeSec": 42.3,
    "sourceTimestamp": "2025-01-27T14:32:15Z",
    "source": "cnc-mill-01"
}

Jetzt hat das Ereignis Bedeutung. Wir wissen, dass dieses Teil zum Fertigungsauftrag FA-12345 gehört, speziell zu Arbeitsgang 20 im Arbeitsplan. Wir können diese Ereignisse aggregieren, um Fragen zu beantworten wie „Wie viele Teile hat dieser Auftrag heute produziert?" oder „Läuft dieser Arbeitsgang schneller oder langsamer als geplant?"

Schritt 4: Das ERP speichert Ausführungsfakten und handelt darauf

Das ERP empfängt dieses Ereignis über seine API und speichert es in einer dedizierten Ausführungsfakten-Tabelle. In der Anfangsphase dient das rein der Transparenz — Produktionsplaner sehen den Fortschritt in Echtzeit, und Meister erkennen Verzögerungen, bevor sie zu Krisen werden.

Wenn das Vertrauen in die Daten wächst, kann das ERP beginnen, auf diese Fakten zu handeln: Istmengen buchen, Materialverbrauch auslösen oder Ist-Kosten basierend auf echten Zykluszeiten aktualisieren. Die Architektur unterstützt beide Modi.

Der komplette Fluss: vom rohen Maschinenereignis zum verankerten Ausführungsdatensatz

Das Mapping-Problem

Einer der kniffligsten Aspekte der Brücke ist das Mapping. Der UNS organisiert Daten nach physischem Standort: Fabrik, Bereich, Linie, Zelle, Gerät. Das ERP organisiert Daten nach Geschäftslogik: Fertigungsaufträge, Arbeitspläne, Arbeitsgänge, Arbeitsplätze.

Diese Hierarchien passen nicht natürlich zusammen. Ein UNS-Topic wie factory/lineA/cell3/laser-cutter könnte dem Arbeitsplatz WC-LASER-01 im ERP entsprechen — aber diese Beziehung ist von keiner Seite offensichtlich.

Die Brücke braucht eine explizite Mapping-Tabelle, die sagt: „Wenn du Ereignisse von diesem UNS-Topic siehst, sollen sie diesem ERP-Arbeitsplatz zugeordnet werden."

Diese Mapping-Tabelle lebt im ERP-System, nicht im Brücken-Code. Das ist wichtig: Es bedeutet, dass Produktionstechniker neue Maschinen zum UNS hinzufügen können, ohne Code-Änderungen zu erfordern. Sie fügen einfach eine Zeile zur Mapping-Tabelle hinzu.

Manche Unternehmen wollen weiter gehen und das ERP neue Topics automatisch „entdecken" lassen. Das klingt zwar praktisch, führt aber zu Mehrdeutigkeiten. Was, wenn ein neues Topic auftaucht, das mehreren Arbeitsplätzen zugeordnet werden könnte? Auto-Discovery kann funktionieren, um Mappings vorzuschlagen, aber ein Mensch sollte sie bestätigen, bevor sie aktiv werden.

Das Datenmodell: Wie UNS-Topics über Arbeitsplätze mit ERP-Fertigungsaufträgen verbunden werden

Mit der chaotischen Realität umgehen

Integration in der echten Welt ist chaotisch. Nachrichten kommen in falscher Reihenfolge an. Das Netzwerk verliert Pakete. Maschinen starten neu und wiederholen alte Ereignisse. Die Brücke muss all das elegant handhaben.

Idempotenz: Dieselbe Nachricht zweimal soll harmlos sein

Jedes Ausführungsereignis trägt eine eindeutige messageId. Wenn das ERP ein Ereignis empfängt, prüft es: Habe ich diese ID schon gesehen? Wenn ja, bestätigt es die Nachricht, verarbeitet sie aber nicht erneut. Das macht die gesamte Pipeline sicher für Wiederholungen — was essenziell ist, wenn man mit unzuverlässigen Netzwerkverbindungen auf dem Shopfloor arbeitet.

Zeitliche Ordnung: Alte Nachrichten sollen neue Fakten nicht überschreiben

Jedes Ereignis trägt einen sourceTimestamp — den Moment, in dem das Ereignis tatsächlich stattfand, nach der Uhr des Quellsystems. Das ERP verfolgt den neuesten Zeitstempel, den es für jeden Fertigungsauftrags-Arbeitsgang gesehen hat. Wenn ein älteres Ereignis nach einem neueren verarbeitet wurde, wird das ältere Ereignis zu Prüfzwecken gespeichert, aktualisiert aber nicht die Zusammenfassungsfelder.

Das klingt nach einem kleinen Detail, ist aber kritisch für Systeme, in denen Ereignisse unterschiedliche Netzwerkpfade nehmen und in falscher Reihenfolge ankommen könnten.

Idempotenz: Doppelte Nachrichten werden sicher ignoriert

Zeitliche Ordnung: Verspätet ankommende alte Ereignisse überschreiben keine neueren Daten

Explizites Scheitern: Im Zweifel ablehnen und erklären

Was passiert, wenn die Brücke ein Ereignis für Arbeitsplatz WC-CNC-01 erhält, aber dort zwei Fertigungsaufträge aktuell zugewiesen sind? Oder keiner?

Das System hat eine Wahl: Raten oder um Klärung bitten.

Wir plädieren stark für den zweiten Ansatz. Die Brücke sollte das Ereignis mit einer klaren Fehlermeldung ablehnen: „Kann nicht auflösen: Arbeitsplatz WC-CNC-01 hat 2 aktive Fertigungsaufträge. Bitte orderNo explizit angeben."

Das mag unbequem erscheinen, verhindert aber ein weit schlimmeres Ergebnis: stillschweigend Produktion dem falschen Auftrag zuzuordnen. Wenn du den Monatsabschluss abstimmst oder ein Qualitätsproblem untersuchst, musst du darauf vertrauen können, dass deine Daten korrekt sind — auch wenn das bedeutet, einige abgelehnte Ereignisse nachträglich zu korrigieren.

Was die ERP-Seite braucht

Damit diese Architektur funktioniert, muss dein ERP-System einige Fähigkeiten bereitstellen (oder du musst sie bauen):

1. Einen API-Endpunkt für den Empfang von Ausführungsereignissen

Die Brücke braucht einen Ort, wohin sie ihre angereicherten Ereignisse senden kann. Das ist typischerweise ein REST-API-Endpunkt, der JSON-Payloads akzeptiert und sie in einer Ausführungsfakten-Tabelle speichert.

2. Referenzdaten-APIs

Die Brücke muss Fertigungsaufträge, Arbeitsplan-Zeilen, Arbeitsplätze und Artikel abfragen können, um ihre Arbeit zu tun. Das sind typischerweise schreibgeschützte Endpunkte.

3. Eine Konfigurations-UI für das Mapping

Jemand muss die Topic-zu-Arbeitsplatz-Mappings pflegen. Eine einfache Listenseite im ERP mit Hinzufügen/Bearbeiten/Löschen-Funktionalität reicht aus.

4. Erweiterungsfelder für Transparenz

Wenn du möchtest, dass Produktionsplaner Echtzeit-Fortschritt auf ihren bestehenden Bildschirmen sehen, musst du Erweiterungsfelder zu Fertigungsauftrags-Seiten hinzufügen. Diese zeigen abgeleitete KPIs (Gesamtmenge produziert, aktuelle Verfügbarkeit usw.) an, ohne die zugrundeliegenden Tabellen zu modifizieren.

Open-Source-Implementierung für Business Central

Für Benutzer von Microsoft Dynamics 365 Business Central haben wir eine vollständige Open-Source-Implementierung von allem hier Beschriebenen gebaut. Der UNS Bridge Connector bietet:

• API-Endpunkte für den Empfang von Ausführungsereignissen
• Die Topic-zu-Arbeitsplatz-Mapping-Tabelle
• Transparenz-Erweiterungen für Fertigungsauftrags-Seiten
• Idempotenz- und Zeitordnungs-Handling
• Vollständiger Quellcode zum Anpassen

Die technische Dokumentation geht tiefer in Implementierungsdetails, einschliesslich Datenbankschema-Design, API-Spezifikationen und Deployment-Patterns.

Die Brücke selbst: Wo läuft sie?

Die Brücke ist ein separater Service — nicht Teil des ERP, nicht Teil der Edge-Geräte. Sie läuft als Middleware, die beide Welten verbindet.

Architektonisch muss sie:

• Relevante MQTT-Topics vom UNS abonnieren
• Eine Verbindung zur ERP-API aufrechterhalten
• Referenzdaten für Performance cachen (Arbeitsplätze, aktive Aufträge)
• Maschinenereignisse in ERP-Ausführungsereignisse transformieren
• Fehler und Wiederholungen elegant handhaben

Du kannst sie in jeder Sprache bauen, die MQTT- und HTTP-Clients unterstützt. Python ist beliebt für Prototypen. Go oder Rust funktionieren gut für Produktions-Deployments, bei denen Ressourceneffizienz wichtig ist. Node.js ist in Ordnung, wenn dein Team damit bereits vertraut ist.

Die Brücke kann on-premises laufen, in der Cloud oder auf einem Edge-Gateway — überall dort, wo sie sowohl den MQTT-Broker als auch die ERP-API erreichen kann. Für Unternehmen mit strikter Netzwerksegmentierung ist es ein gängiges Muster, sie auf einem dedizierten Gateway im OT-Netzwerk zu betreiben (mit ausschliesslich ausgehenden Verbindungen zum ERP).

Typisches Deployment: Brücke in der OT-Zone mit ausschliesslich ausgehender Verbindung zum Cloud-ERP

Was du gewinnst

Wenn die Brücke betriebsbereit ist, werden mehrere Dinge möglich, die vorher nicht möglich waren:

Echtzeit-Produktionstransparenz. Planer sehen den Auftragsfortschritt, während er passiert, nicht erst beim letzten manuellen Dateneintrag. Das ermöglicht schnellere Reaktion auf Probleme und genauere Liefertermin-Schätzungen.

Ausführungsfakten auf ERP-Ebene. Manche Daten vom Shopfloor sind direkt relevant für ERP-Prozesse. Tatsächliche Zykluszeiten ermöglichen genauere Kalkulationen. Echte Istmengen können in Abweichungsanalysen einfliessen. Maschinenverfügbarkeit beeinflusst die Kapazitätsplanung. Es geht nicht darum, MES zu ersetzen — es geht darum, Ausführungsfakten dort verfügbar zu machen, wo sie für Geschäftsentscheidungen gebraucht werden.

Audit-Trail als Standard. Jedes Ausführungsereignis wird mit seinem Quell-Zeitstempel und seiner Message-ID gespeichert. Du kannst exakt nachvollziehen, was passiert ist, wann und warum.

Fundament für automatisierte Buchungen. Sobald Ausführungsdaten zuverlässig fliessen und du ihrer Qualität vertraust, wird der Weg zu automatisierten Istmeldungen und Verbrauchsbuchungen viel kürzer. Die Infrastruktur ist bereits vorhanden.

Was es nicht tut

Um Erwartungen realistisch zu halten, sei klar, was diese Architektur nicht tut:

• Sie ersetzt kein MES. Wenn du Workflow-Enforcement, detaillierte Arbeitsanweisungen oder Echtzeit-Produktionsplanung brauchst, brauchst du weiterhin ein MES. Diese Architektur macht Ausführungsfakten im ERP sichtbar — sie steuert nicht die Ausführung.
• Sie handhabt keine Stammdatenpflege. Arbeitsplätze, Arbeitspläne und Artikel werden im ERP wie gewohnt erstellt und gepflegt. Die Brücke liest diese Daten nur.
• Sie löst nicht alle Datenqualitätsprobleme. Wenn deine Fertigungsaufträge im ERP falsch sind, wird die Brücke pflichtbewusst Fortschritt gegen falsche Daten melden. Garbage in, garbage out.

Erste Schritte

Wenn du bereit bist, deine eigene ERP-UNS-Brücke zu bauen, hier ist eine praktische Reihenfolge:

1. Beginne mit einem Arbeitsplatz. Wähle eine Maschine, die bereits Ereignisse in deinen UNS publiziert. Verbinde sie mit einem Fertigungsauftrag in deinem ERP. Stelle sicher, dass du ein Zyklusereignis den ganzen Weg durch bis zu einem Ausführungsdatensatz verfolgen kannst.

2. Baue die Mapping-Infrastruktur. Erstelle die Topic-zu-Arbeitsplatz-Mapping-Tabelle. Entscheide, ob du Auto-Discovery mit Bestätigung willst oder rein manuelles Mapping.

3. Handle die Randfälle. Teste, was passiert, wenn eine Nachricht zweimal ankommt. Teste, was passiert, wenn ein Arbeitsplatz keinen aktiven Auftrag hat. Teste, was passiert, wenn die ERP-API nicht erreichbar ist. Diese Szenarien werden in der Produktion auftreten.

4. Füge Transparenz zum ERP hinzu. Sobald Ausführungsdaten fliessen, erweitere deine Fertigungsauftrags-Bildschirme, um sie anzuzeigen. Hier beginnen Stakeholder, Wert zu sehen.

5. Erweitere schrittweise. Füge mehr Arbeitsplätze, mehr Produktionslinien, mehr Datenpunkte hinzu. Jede Erweiterung sollte inkrementell und reversibel sein.

Für diejenigen, die Microsoft Dynamics 365 Business Central nutzen, handhabt unser Open-Source UNS Bridge Connector die Schritte 2-4. Du baust den Brücken-Service (Schritt 1) und konfigurierst ihn für deine spezifische UNS-Topologie. Die Erweiterung stellt die ERP-seitige Infrastruktur bereit — API-Endpunkte, Mapping-Tabellen und Transparenz-Erweiterungen.

Für Implementierungsdetails, Datenmodell-Dokumentation und Deployment-Guides, siehe die Shopfloor Execution Bridge Dokumentation.

Fazit

Der Unified Namespace wird oft als Shopfloor-Technologie diskutiert — eine Möglichkeit, Maschinen miteinander und mit Analysesystemen sprechen zu lassen. Das stimmt, aber es ist nur die halbe Geschichte.

Der volle Wert eines UNS entsteht, wenn operative Daten auf Geschäftskontext treffen. Wenn Zykluswerte zu Produktionsfortschritt werden. Wenn Maschinenereignisse zu Auftragsstatus werden. Wenn Sensordaten zu entscheidungsrelevanten Informationen werden.

Diese Brücke zu bauen erfordert Sorgfalt. ERP-Systeme sind kritische Infrastruktur mit komplexen, miteinander verflochtenen Prozessen. Beginne mit Beobachten, baue Vertrauen in die Daten auf, dann erweitere die Autorität, während das Vertrauen wächst.

Ob du das selbst baust oder unsere Open-Source-Komponenten nutzt, die Prinzipien bleiben dieselben: Respektiere die Autorität des ERP, mappe explizit zwischen den Welten, handle Randfälle elegant und lass die Integration von Transparenz zu Automatisierung reifen.

Die Maschinen sprechen bereits. Es ist Zeit, deinem ERP beim Zuhören zu helfen.

Der UNS Bridge Connector für Business Central ist Open Source und auf GitHub verfügbar. Technische Dokumentation findest du in den Shopfloor Execution Bridge Docs. Für Hilfe bei der Implementierung dieses Musters in deinem Unternehmen kontaktiere uns.