MES-ERP-Schnittstelle: welches Integrationsmuster wann trägt

Eine MES-ERP-Schnittstelle transportiert vier Dinge: Stammdaten und Fertigungsaufträge vom ERP nach unten, Rückmeldungen und Materialbewegungen aus der Fertigung nach oben. Welches Integrationsmuster dafür trägt – Nachrichtenformat des ERP, REST-API, OPC UA, Dateiaustausch oder Middleware – hängt weniger von der Technik ab als vom Mengengerüst, der Echtzeitanforderung und davon, wer die Schnittstelle nachts um drei betreibt. Dieser Artikel liefert die Entscheidungsmatrix und danach das, woran Kopplungen im Betrieb tatsächlich scheitern: Rückmeldelogik, doppelte Meldungen und Ausfälle.

Was zwischen MES und ERP tatsächlich fließt

Zwischen MES und ERP fließen vier Datenströme: Stammdaten abwärts, Fertigungsaufträge abwärts, Rückmeldungen aufwärts und Materialbewegungen in beide Richtungen. Alles andere – Qualitätsdaten, Instandhaltungsaufträge, Personalzeiten – ist eine Variante davon oder gehört in eine eigene Schnittstelle. Als Definition genügt deshalb: Eine ERP-Schnittstelle ist ein festgelegter Kanal mit vereinbartem Datenmodell, über den ein anderes System Daten mit dem ERP austauscht – und der entscheidende Teil ist das Datenmodell, nicht der Kanal.

Die Norm dafür ist ISA-95, international als IEC 62264 geführt. Laut dem ISA-95-Komitee definiert der Standard die Schnittstelle zwischen Steuerungsfunktionen und übrigen Unternehmensfunktionen auf Basis des Purdue-Modells, zunächst die Schnittstelle zwischen dessen Ebenen 3 und 4. IEC 62264-1:2013 beschreibt laut IEC-Webstore die Domäne des Fertigungsmanagements (Ebene 3), ihre Aktivitäten sowie Schnittstelleninhalt und Transaktionen innerhalb von Ebene 3 und zwischen Ebene 3 und Ebene 4. Für die ISA-95-Integration von ERP und MES heißt das: Die Norm liefert Begriffe und Objektmodelle, kein Protokoll und keine Produktempfehlung.

Maschinen selbst sprechen nicht mit dem ERP. Wer Maschinendaten ins ERP bringen will, braucht eine Verdichtungsstufe: Aus Zählerständen, Taktzeiten und Störmeldungen der Ebene 2 muss eine Rückmeldung mit Bezug auf Auftrag und Arbeitsgang werden. Das leistet ein MES, ein Betriebsdatensystem oder eine schlanke Zwischenschicht – ein ERP, das rohe Maschinensignale entgegennimmt, ist dagegen nur eine Datenbank voller Zählerstände ohne Auftragsbezug. Woher diese Maschinensignale überhaupt kommen – und was zu tun ist, wenn eine Anlage gar keine Schnittstelle hat –, steht in Maschinendaten in Bestandsanlagen nachrüsten.

Die fünf Integrationsmuster im Vergleich

Für die MES-ERP-Schnittstelle gibt es fünf gängige Muster, und keines gewinnt in allen Kriterien. Die Entscheidung fällt über sieben Fragen: Auftragsvolumen pro Tag, fachlich nötige Latenz, ERP-Typ (On-Premise-System mit eigenem Nachrichtenformat oder Cloud-ERP mit freigegebener API), Änderungsfrequenz von Feldern und Prozessen, Betriebskompetenz im eigenen Haus, Fehlersichtbarkeit und Lock-in.

Zwei Anmerkungen zur Tabelle. Erstens: Eine API-Schnittstelle zum ERP-System klingt modern, ist aber synchron – fällt das ERP aus, steht der Aufrufer ohne Antwort da, und der Puffer muss im MES oder in einer Zwischenschicht liegen. Zweitens: OPC 10030, die OPC-UA-Companion-Specification für das ISA-95-Objektmodell, deckt in Version 1.00 nach eigener Angabe nur eine Teilmenge des Standards ab, nämlich die Objektmodelle für Personal, Equipment, Physical Asset und Material. Operations Schedule und Operations Performance – also Aufträge und Rückmeldungen – sind ausdrücklich späteren Fassungen vorbehalten. OPC UA trägt damit die Stammdaten- und Ressourcensicht bis auf die Maschine, ersetzt aber keine Auftragsschnittstelle.

Datenmodell und Mapping: woran Projekte wirklich scheitern

Kopplungsprojekte scheitern selten am Protokoll und häufig am Mapping. Der ERP-Artikel heißt anders als das MES-Produkt, die Maschine kennt nur eine Programmnummer, und dieselbe Anlage trägt drei Namen: Kostenstelle im ERP, Arbeitsplatz im MES, Stationsbezeichnung in der Steuerung. Solange diese Zuordnungen in Köpfen und Excel-Listen leben, ist die Schnittstelle nicht betriebsfähig.

Ein gemeinsames Vokabular hilft, auch wenn Sie es nie vollständig implementieren. ISA-95 benennt vier Informationsarten, die zwischen Systemen des Fertigungsmanagements ausgetauscht werden: Eigenschaften von Material, betriebliche Angaben zu Equipment, die Zusammensetzung physischer Assets sowie Qualifikationen und Rollen von Personal. Genau diese vier Objektmodelle bildet OPC 10030 auf OPC UA ab. B2MML wiederum ist die offene XML-Umsetzung der ISA-95-Datenmodelle, gepflegt von MESA International – inzwischen auch als JSON-Schema-Variante, die MESA selbst als noch nicht formal verifiziert kennzeichnet.

Der praktische Nutzen: Wenn Ihr Mapping-Dokument die Begriffe Equipment, Material, Personnel und Operations Schedule verwendet, sprechen ERP-Berater, MES-Anbieter und Automatisierer über dieselben Dinge – unabhängig davon, ob am Ende XML, JSON oder eine CSV-Datei transportiert wird. Entscheidend ist, dass jedes Feld genau ein führendes System hat und Umrechnungsfaktoren als Stammdaten gepflegt werden, nicht als Konstanten im Schnittstellencode.

Rückmeldelogik: Mengen, Zeiten und Status korrekt zurückschreiben

Die Rückmeldung aus der Produktion ans ERP ist der Teil der Schnittstelle, an dem fachliche Fehler am teuersten sind, weil sie Bestände, Kosten und Liefertermine verfälschen. Bevor eine Zeile Code geschrieben wird, muss eine Frage entschieden sein: Welches System führt die Wahrheit über den Auftragsfortschritt? Es gibt nur zwei tragfähige Antworten. Entweder das MES führt den Fortschritt und das ERP übernimmt ihn ungeprüft, oder das ERP führt ihn und das MES meldet nur Ereignisse. Mischformen, in denen beide Systeme korrigieren dürfen, erzeugen nach dem ersten Ausfall zwei Wahrheiten.

Teilrückmeldung

Meldet Menge und Zeit zu einem Arbeitsgang, ohne ihn abzuschließen. Restmenge und Restzeit werden fortgeschrieben; mehrere Teilrückmeldungen pro Schicht sind der Normalfall.

Endrückmeldung

Schließt den Arbeitsgang ab. Eine verspätete Teilrückmeldung danach ist ein fachlicher Fehlerfall, der sichtbar werden muss – nicht stillschweigend verbucht oder verworfen.

Gutmenge und Ausschuss

Werden getrennt gemeldet, meist mit Ausschussgrund. Gut plus Ausschuss plus Nacharbeit ergibt die produzierte Menge; fehlt eine der drei Größen, stimmen Bestand oder Kennzahlen nicht.

Nacharbeit

Ist je nach ERP eine eigene Mengenart oder ein eigener Arbeitsgang. Klären Sie vor dem Mapping, welche Variante Ihr ERP kennt – die Schnittstelle kann das nicht nachträglich umdeuten.

Zeitrückmeldung

Rüst- und Bearbeitungszeit mit Bezug auf Arbeitsgang und, wo zulässig, Person. Maschinenzeit aus der Steuerung und Personenzeit vom Terminal sind zwei verschiedene Größen.

Korrekturbuchung

Erfolgt nie durch Löschen, sondern durch eine Gegenbuchung mit Bezug auf die Originalmeldung. Nur so bleibt der Verlauf nachvollziehbar und eine Korrektur selbst wieder korrigierbar.

Idempotenz und Dublettenschutz

Jede Rückmeldung braucht eine eindeutige fachliche Nachrichten-ID, weil jede Verbindung irgendwann genau dann abbricht, wenn das ERP die Buchung schon verarbeitet, die Bestätigung aber noch nicht gesendet hat. Der Sender weiß dann nicht, ob die Meldung angekommen ist, und wiederholt sie. Ohne Dublettenschutz verdoppelt sich die Menge im ERP. RFC 9110 fasst das Prinzip für HTTP so: Eine Methode gilt als idempotent, wenn mehrere identische Anfragen auf dem Server dieselbe beabsichtigte Wirkung haben wie eine einzige – PUT und DELETE sind idempotent, POST ist es nicht. Eine Rückmeldung per POST ohne fachliche ID ist deshalb per Definition nicht gefahrlos wiederholbar.

Dasselbe Problem hat in jedem Nachrichtenprotokoll einen Namen. Der OASIS-Standard MQTT 5.0 definiert drei Zustellgarantien: Bei QoS 0 („at most once“) kann eine Nachricht verloren gehen, bei QoS 1 („at least once“) kommt sie sicher an, aber Duplikate können auftreten, bei QoS 2 („exactly once“) kommt sie genau einmal an. Die Praxiserfahrung dazu: „Exactly once“ gilt zwischen Client und Broker, nicht zwischen Maschine und ERP-Buchung. Sobald ein Adapter, eine Datenbank oder ein Neustart dazwischenliegt, sind Sie wieder bei „at least once“. Robust ist deshalb die Kombination aus Zustellung mindestens einmal und einem Empfänger, der Wiederholungen anhand der ID erkennt und verwirft.

{
  "messageId": "MES-4711-0020-2026-09-21T06:14:03Z-000917",
  "sequence": 917,
  "orderNo": "4711",
  "operationNo": "0020",
  "workCenter": "WP-120",
  "type": "PARTIAL_CONFIRMATION",
  "goodQty": 240,
  "scrapQty": 3,
  "scrapReason": "Q-07",
  "unit": "PCE",
  "machineTimeSec": 2880,
  "postedAt": "2026-09-21T06:14:03Z",
  "correctsMessageId": null
}

Vier Regeln machen das Beispiel betriebsfähig. Die messageId wird im MES beim Erzeugen der Meldung vergeben, nicht beim Senden – ein Wiederholungsversuch trägt dieselbe ID. Der ERP-Adapter hält eine Tabelle verarbeiteter IDs und quittiert ein Duplikat mit demselben Erfolg wie beim ersten Mal, ohne erneut zu buchen. Die sequence je Arbeitsgang macht Lücken und Vertauschungen erkennbar. Und ein Storno ist eine neue Nachricht mit eigener ID, die über correctsMessageId auf das Original zeigt – niemals eine Löschung.

Fehlerfälle: wenn MES, ERP oder das Netz ausfallen

Eine Schnittstelle, die nur den Gutfall beherrscht, ist ein Prototyp. Im Betrieb entscheidet das Verhalten in fünf Situationen, die Tabelle 04 beschreibt – jeweils mit der Frage, wer den Fehler sieht und wer ihn auflösen darf.

Der wichtigste Schnitt in dieser Tabelle ist der zwischen technischen und fachlichen Fehlern. Ein technischer Fehler – Netz weg, Zertifikat abgelaufen, Dienst neu gestartet – verschwindet durch Wiederholung. Ein fachlicher Fehler – Auftrag abgeschlossen, Artikel gesperrt, Menge über Sollmenge – verschwindet nie durch Wiederholung. Wer beide gleich behandelt, füllt das Log mit tausend Wiederholungen derselben Ablehnung oder verwirft technische Fehler zu früh. Die Dead-Letter-Queue gehört deshalb der Fertigungssteuerung, mit einem Klartextgrund, den jemand ohne Logzugriff versteht.

Direktkopplung oder Middleware?

Eine Punkt-zu-Punkt-Kopplung bleibt sinnvoll, solange genau zwei Systeme beteiligt sind, die Formate stabil bleiben und ein Team beide Seiten kennt. Eine Middleware zwischen MES und ERP – oder allgemeiner ein Unified Namespace, in dem alle Systeme über einen Broker publizieren und abonnieren – wird zur besseren Antwort, sobald eine der folgenden Bedingungen eintritt.

• —Ein drittes System will dieselben Rückmeldungen – Qualitätssystem, Energiemonitoring, Instandhaltung, Dashboard. Mit Direktkopplungen wächst die Zahl der Verbindungen quadratisch mit der Zahl der Systeme.
• —Das ERP steht vor einem Releasewechsel oder einer Migration; eine Zwischenschicht hält das Fertigungsmodell stabil, während sich die ERP-Seite ändert.
• —Die Fehlerbehandlung aus Tabelle 04 müsste sonst in jeder Direktkopplung neu gebaut werden.

Ehrlich benannt werden müssen die Kosten: Eine Middleware ist ein weiteres System mit Lizenzen, Updates, Zertifikaten und einem Team, das sie versteht. Sie verschiebt Komplexität, sie beseitigt sie nicht. Wer den Weg geht, sollte vorher festlegen, wem die Plattform gehört – IT oder Produktion – und wie das Topic- oder Nachrichtenschema aussieht. Ein konkretes ISA-95-Topic-Schema und die Frage nach dem Single Point of Failure behandelt der Beitrag zum Unified Namespace als Architektur für Maschinen- und Auftragsdaten.

Der Gesprächsleitfaden für den ERP-Anbieter

Die meisten teuren Überraschungen einer MES-ERP-Schnittstelle sind vor dem Angebot bekannt – wenn jemand danach fragt. Die folgende Liste gehört in das Gespräch mit dem ERP-Anbieter oder dem internen ERP-Team, die Antworten schriftlich ins Lastenheft.

Vorgehen und Abnahmekriterien

Die Reihenfolge ist in fast jedem Projekt dieselbe: erst Stammdaten, dann Auftragsversorgung, dann Rückmeldung, dann Material. Wer mit der Rückmeldung beginnt, weil sie den sichtbarsten Nutzen verspricht, bucht sauber gemeldete Mengen auf Artikel und Arbeitsplätze, die noch nicht abgestimmt sind.

1. 01

   Führendes System und Mapping festlegen

   Für jedes Feld aus Tabelle 03 ein führendes System benennen, Umrechnungsfaktoren als Stammdaten anlegen und das Mapping als Dokument mit Versionsstand ablegen. Ohne diesen Schritt ist kein späterer Test reproduzierbar.

2. 02

   Stammdaten synchronisieren

   Artikel, Arbeitspläne und Arbeitsplätze vom ERP ins MES übertragen und einen Abgleichbericht erzeugen: Was fehlt, was ist doppelt, was hat keine Entsprechung. Erst wenn dieser Bericht leer ist, geht es weiter.

3. 03

   Auftragsversorgung aufbauen

   Fertigungsaufträge inklusive Änderungen und Stornierungen übertragen. Der kritische Test ist nicht der neue Auftrag, sondern die Terminänderung an einem Auftrag, der im MES bereits begonnen wurde.

4. 04

   Rückmeldung mit Dublettenschutz einführen

   Teil- und Endrückmeldung, Ausschuss und Zeiten zurückschreiben, Nachrichten-IDs und Dead-Letter-Queue einrichten, Monitoring für die Schichtleitung bereitstellen – zunächst parallel zum bisherigen Verfahren.

5. 05

   Materialbewegungen anbinden

   Entnahmen und Zugänge zuletzt, weil sie Bestände verändern und die meisten fachlichen Sonderfälle enthalten. Wie der Zugang selbst digital wird, zeigt der Beitrag zur Digitalisierung des Wareneingangs vom Lieferschein bis zur Buchung.

6. 06

   Parallelbetrieb auswerten und abnehmen

   Mindestens einen vollständigen Planungszyklus lang beide Verfahren laufen lassen, Abweichungen täglich auswerten und die Abnahme an die Testfälle unten binden – nicht an ein Datum.

Ersetzt die Schnittstelle bisher eine von Hand gepflegte Excel-Liste, liefert der Parallelbetrieb zugleich den Beleg dafür, wie viele Fehler die manuelle Übertragung erzeugt hat. Wann diese Ablösung reif ist und in welchen Stufen sie gelingt, beschreibt der Beitrag über Kipppunkte beim Ablösen von Excel in der Fertigungssteuerung.

1. 01Teilrückmeldung: Drei Teilmengen auf einen Arbeitsgang, danach Endrückmeldung – Summen in MES und ERP stimmen überein, Restmenge ist null.
2. 02Dublette: Dieselbe Nachricht dreimal senden – im ERP existiert genau eine Buchung, der Sender erhält dreimal eine Erfolgsantwort.
3. 03Storno: Eine gebuchte Teilrückmeldung stornieren und mit korrigierter Menge neu melden – Verlauf nachvollziehbar, Bestand korrekt.
4. 04ERP-Ausfall: ERP-Testsystem 30 Minuten anhalten, währenddessen 50 Meldungen erzeugen – nach Wiederanlauf sind alle 50 in richtiger Reihenfolge gebucht, der Stau-Zähler war sichtbar.
5. 05Fachliche Ablehnung: Teilrückmeldung auf einen endgemeldeten Arbeitsgang – landet mit Klartextgrund in der Dead-Letter-Queue, wird nicht wiederholt.
6. 06Mengengerüst: Das freigegebene Volumen einer Stunde in zehn Minuten senden – keine Verluste, Latenz innerhalb der vereinbarten Grenze.
7. 07Abgleichlauf: Nach dem Ausfalltest den Abgleich je Auftrag ausführen – der Bericht zeigt null Abweichungen oder genau die absichtlich erzeugten.

Diese sieben Testfälle sind zugleich die Abnahmekriterien. Sie gehören mit erwarteten Ergebnissen ins Lastenheft, bevor ein Anbieter kalkuliert – nicht in eine nachgereichte Wunschliste. Wie ein solches Dokument aufgebaut ist, steht im Beitrag zum Aufbau eines Lastenhefts für Industriesoftware.

Fazit

Die MES-ERP-Schnittstelle ist keine Protokollfrage. ISA-95 liefert das Vokabular, die fünf Muster liefern Optionen – tragfähig wird die Kopplung erst durch drei Entscheidungen, die vor der Technik fallen: welches System den Auftragsfortschritt führt, wie Dubletten erkannt werden und was passiert, wenn eine Seite ausfällt. Wer diese drei Punkte im Lastenheft und in den Abnahmetests verankert, kann das Integrationsmuster fast frei nach Mengengerüst und Betriebskompetenz wählen.

Der nächste Schritt ist kein Angebot, sondern das Mapping-Dokument aus Tabelle 03 und die Antworten auf den Fragenkatalog an den ERP-Anbieter. Wenn Sie dafür eine Zwischenschicht brauchen, die Maschinendaten verdichtet, puffert und mit fachlicher ID ans ERP übergibt, zeigen die Lösungen von ralwo für Maschinendaten und Schnittstellen, wie eine solche Schicht typischerweise aufgebaut ist.