Was ist ein MES? Aufgaben, Abgrenzung zum ERP und die Schnittstellen

Der Begriff steht für Manufacturing Execution System, auf Deutsch üblicherweise Fertigungsleitsystem oder Produktionsleitsystem. Die deutsche Übersetzung ist im Sprachgebrauch allerdings selten, in Projekten ist meist einfach von „MES“ die Rede.

Ein MES deckt typischerweise sechs Aufgabenfelder ab: Feinplanung der Aufträge auf Anlagen und Schichten, Betriebs- und Maschinendatenerfassung, Qualitätssicherung mit Prüfplänen und Sperrentscheidungen, Rückverfolgbarkeit über Chargen und Seriennummern, Instandhaltung mit Wartungsplänen, und Personalzeiten an der Anlage. Nicht jeder Betrieb braucht alle sechs, und die Produkte setzen ihre Schwerpunkte verschieden.

In Deutschland beschreibt die VDI-Richtlinie 5600 die Aufgaben eines MES; MES heißen dort Fertigungsmanagementsysteme. In der Ausgabe von 2016 zählt sie zehn MES-Aufgaben, darunter auch Material-, Informations-, Energie- und Auftragsmanagement sowie die Leistungsanalyse, und richtet sich als Leitfaden auch an die Beteiligten bei Auswahl und Einführung eines MES.

Was ein MES leistet und wie man eines auswählt, behandelt ausführlich Was ist ein MES auf manubes. Hier geht es um die Frage danach: wie es mit dem Rest des Hauses Daten austauscht.

Das MES sitzt in der Automatisierungspyramide auf der Betriebsleitebene, in ISA-95 auf Level 3. Darüber liegt in beiden Modellen das ERP (Unternehmensebene bzw. Level 4). Darunter zählen die Modelle verschieden: Die Pyramide führt Prozessleit-, Steuerungs- und Feldebene, ISA-95 die Level 2 bis 0.

Diese Ordnung beschreibt Zuständigkeiten. Die Datenwege folgen ihr nicht mehr durchgehend: Wo kein MES steht, liest das ERP die Werte eine Ebene tiefer, in der Praxis häufig auf der Prozessleitebene der Pyramide. Wann ein Betrieb ohne MES auskommt, steht weiter unten unter „Braucht jede Fertigung ein MES?“.

Mehr dazu: Was ist ISA-95? Fünf Ebenen, IEC 62264 und die Automatisierungspyramide

Nein, aber SAP kann Teile davon.

SAP ist im Kern ein ERP. Es plant gegen den Markt: Aufträge, Termine, Material, Kapazitäten, Kosten. Für die Fertigungsebene gibt es Erweiterungen und eigene Produkte, die MES-Aufgaben übernehmen. Ein Standard-SAP ohne diese Erweiterungen ist aber kein MES, und vor allem fehlt ihm der Zeittakt.

Ein ERP rechnet in Aufträgen und Tagen, ein MES in Arbeitsgängen und Minuten.

In der Praxis findet man deshalb drei Aufteilungen: SAP plant und ein MES führt aus; SAP übernimmt beides mit Zusatzmodulen; oder es gibt kein MES und SAP wird direkt aus der Fertigung bedient. Welche passt, hängt daran, wer im Unternehmen den Fertigungsplan verantwortet.

Beide planen, aber in verschiedenen Zeiträumen und mit verschiedener Auflösung.

Die Rückmeldung läuft in die Gegenrichtung: Das MES meldet dem ERP, was tatsächlich produziert wurde. An dieser Rückmeldung werden in vielen Betrieben Daten zweimal erfasst, einmal an der Maschine und einmal von Hand im ERP. Wo das passiert, liegt das Problem häufig in der Schnittstelle dazwischen und nicht im MES selbst.

Nein. Ob ein Betrieb eines braucht, ist vor der Auswahl zu klären.

Die Norm ISA-95 beschreibt für diese Ebene Aufgaben: Aufträge zerlegen, Chargen verfolgen, zurückmelden. Ein Produkt, das alles davon kann, schreibt sie nicht vor.

Ob ein MES von der Stange passt, hängt daran, wie viel davon ein Betrieb wirklich braucht. Bringt es Funktionen mit, die nie benutzt werden, und verlangt es dafür Prozesse, die nicht zum Haus passen, entsteht Aufwand beim Einführen und bei jeder späteren Anpassung.

Auf dieser Ebene sind drei Wege üblich:

Am stärksten verändert hat sich der mittlere Weg. Für diese Aufgaben waren früher Entwickler nötig. Heute können Fachabteilungen sie auf einer No-Code-Plattform per Drag-and-Drop selbst bauen. Im Haus steht dafür manubes: Dashboards, Workflows und Reporting setzen dort die Mitarbeitenden zusammen, die den Prozess kennen, ohne Umweg über die IT.

Beim dritten Weg übernimmt der Datenvermittler den Datenweg, den sonst das MES bedient. Er liest die Werte an der Maschine, rechnet sie in die Form um, die das ERP erwartet, und meldet zurück. MES-Aufgaben wie Feinplanung, Rückverfolgbarkeit oder Qualitätsentscheidungen gehören nicht dazu. Was dieser Weg für die Belastbarkeit im Störfall heißt, steht weiter unten unter „Eine Meldung kann warten, eine Rückfrage nicht“.

Die drei Wege schließen sich nicht aus. Ein Betrieb kann ein MES für die Fertigung haben und die Instandhaltung selbst bauen. Welche dieser Aufgaben anfallen, entscheidet über den Zuschnitt. Die Abwägung im Einzelnen behandelt MES: Make or Buy?

Zwischen ERP und Fertigung fließen Daten in zwei Richtungen. Nach unten gehen Aufträge und Stammdaten, etwa Materialstämme und Rezepturen. Nach oben kommen Rückmeldungen mit produzierten Mengen, Materialverbräuchen und Ausschuss.

Unabhängig vom ERP-Produkt sind vier Kanäle üblich: Webdienste über REST oder SOAP; Datenbanken und Zwischentabellen, auf die beide Seiten per SQL oder ODBC zugreifen; Dateien, etwa im CSV-Format, die ein System ablegt und ein anderes einliest; und die herstellereigenen Schnittstellen des jeweiligen ERP.

Am Beispiel SAP, einem in der Fertigung häufigen ERP, sind drei Verfahren üblich. Sie unterscheiden sich vor allem im Zeitverhalten.

Wann nimmt man IDoc, wann RFC?

IDoc ist asynchron. SAP legt die Nachricht ab, ein Empfänger holt sie sich, und die Verarbeitung quittiert später mit einem Statuscode zurück. Das ist der passende Weg für Produktionsaufträge und Mengenrückmeldungen: Der Sender muss nicht warten, und wenn der Empfänger kurz nicht erreichbar ist, bleibt die Nachricht in der Warteschlange stehen. Gesichert ist damit die Zustellung, nicht die Verarbeitung.

Ein synchroner RFC-Aufruf (sRFC) wartet auf die Antwort. Der Aufruf geht hin, die Antwort kommt zurück, und erst dann arbeitet der Aufrufer weiter. Das passt, wenn eine Auskunft sofort gebraucht wird, etwa eine Materialprüfung an der Anlage. Für Massendaten passt es nicht, weil jede Verzögerung auf der einen Seite die andere blockiert. RFC kennt daneben asynchrone und transaktionale Varianten; über den transaktionalen RFC werden die IDocs selbst übergeben.

Die Rückmeldung gehört in beide Richtungen dazu. Ein Transfer, der ohne Meldung ausfällt, bleibt länger unbemerkt als einer, der mit Fehlermeldung abbricht. Ein sauberer Aufbau meldet deshalb zurück, ob die Übergabe geklappt hat, mit drei unterscheidbaren Zuständen: erfolgreich, abgebrochen und fehlerhaft. Ein Abbruch ist dabei kein Fehler, sondern eine geordnete Entscheidung, etwa wenn eine Abfrage keine Daten liefert. Werden beide Fälle zusammengefasst, beginnt die Fehlersuche später an der falschen Stelle.

Mehr dazu: SAP-Anbindung in der industriellen Produktion · SAP-Schnittstellen im Überblick

Die typischen Störungen an dieser Grenze hängen weniger am eingesetzten Produkt als an der Arbeitsweise der Strecke: ob sie asynchron oder synchron überträgt, wo sie Meldungen vorhält, und mit welchen Rechten sie auf das ERP zugreift. Die Beispiele stammen aus der SAP-Anbindung; bei anderen ERP treten dieselben Muster mit anderen Objektnamen auf. Der OPC Router hat für die oben genannten Kanäle eigene Plug-ins: REST, SOAP-Webdienste, ODBC und Datenbanken wie SQL Server oder Oracle, dazu Datei- und CSV-Objekte. Die SAP-Anbindung ist ein eigenes Plug-in und muss lizenziert sein. Die Einrichtung im Einzelnen steht in der Checkliste am Ende dieses Abschnitts.

Eine Quittung bestätigt die Zustellung, nicht die Verarbeitung

Schickt SAP ein IDoc an ein angebundenes System, wird der auslösende Aufruf sofort quittiert, noch bevor die Verarbeitung begonnen hat. Im ERP gilt die Nachricht damit als zugestellt. Ob sie auch verarbeitet wurde, ist dort nur ablesbar, wenn eine zweite, eigene Rückmeldung eingerichtet ist.

Die Ursache: Zustellung und Verarbeitung sind zwei getrennte Vorgänge, und nur der erste ist im Protokoll vorgesehen. Eine Wiederholung nach einem Neustart richtet sich deshalb danach, welche Nachrichten nicht quittiert sind, nicht danach, welche nicht verarbeitet wurden.

Im Betrieb: Ein Auftrag kommt im empfangenden System zweimal an, immer nach einem Neustart oder einem Verbindungsabriss auf der Rückrichtung. Oder umgekehrt: Die Nachricht steht als versendet, in der Fertigung ist nie etwas angekommen.

Was beim Betrieb liegt: Ob eine wiederholte Nachricht ein zweites Mal bucht, entscheidet die Verarbeitung im empfangenden System. Dort muss sie als Wiederholung erkennbar sein, über einen fachlichen Schlüssel und eine Dublettenprüfung. Und ein zurückgemeldeter Status muss auf der sendenden Seite ausgewertet werden.

Im OPC Router: Er kann das Ergebnis der Verarbeitung als eigenen Statussatz nach SAP zurückschreiben, über eine eigene RFC-Verbindung statt über den auslösenden Aufruf. Die Wiederholung beim Start hängt dann an dieser Quittung statt an der Zustellung. Geht ein IDoc an SAP, führt SAP den Verarbeitungsstatus selbst, und der OPC Router kann ihn abfragen.

Eine Meldung kann warten, eine Rückfrage nicht

Zwischenspeichern und später senden gilt als die Antwort auf „was, wenn die Verbindung abreißt“. Wo die Strecke auch Abfragen stellt, deckt es nur einen Teil ab.

Die Ursache: Ein Puffer verschiebt einen Vorgang in der Zeit. Das geht bei einer Meldung, die nur ankommen muss, aber nicht bei einer Frage, deren Antwort im selben Flow gebraucht wird (so heißt im OPC Router ein Ablauf): Die Antwort käme nach der Entscheidung. Eine ERP-Strecke, die meldet und abfragt, teilt sich damit in zwei Hälften. Die Rückmeldung produzierter Mengen kann warten, die Materialprüfung an der Anlage nicht. Beide Hälften brauchen verschiedene Ausfallkonzepte und gehören bei der Planung früh getrennt.

Was beim Betrieb liegt: Erstens braucht jeder Datensatz einen eigenen Zeitstempel aus der Quelle. Wird ein Datensatz nachgereicht, während neue weiterlaufen, kommt er nicht zwingend in der Reihenfolge der Erfassung an, und den Zeitstempel kann keine Software nachträglich erfinden. Zweitens die Aufteilung, welcher Flow warten darf. Drittens die Bemessung: Bei Store & Forward sollten Vorhaltezeit und Speicherkapazität, beim Transferstatus-Trigger Zahl und Abstand der Wiederholungen (siehe Checkliste) die längste geplante Wartung des Zielsystems abdecken; deren Dauer kennt nur das eigene Haus. Viertens, was in der synchronen Hälfte ohne Antwort gilt: ein Ersatzwert, ein Stillstand oder eine Sperre. Das legt die Fertigung fest.

Im OPC Router: In der Meldungshälfte puffert das Add-on Store & Forward. Es lässt sich in der Regel an allen Transferobjekten einsetzen, die am Ende eines Flows stehen, also auch an den SAP-Transferobjekten; ob es an einem bestimmten Transferobjekt greift, zeigt nach dem Einschalten das Store-and-Forward-Symbol. Die Produktseite des Add-ons grenzt es auf Kanäle ein, „die keine zu verarbeitende Rückantworten erwarten“. Ausgenommen ist damit etwa ein RFC-Aufruf, dessen Rückgabe der Flow auswertet: Er gehört in die synchrone Hälfte.

Wiederholen lässt sich ein Aufruf auch ohne Store & Forward, mit einem Try/Catch-Transferobjekt: ein bis vier weitere Versuche, mit konstanter, linear oder exponentiell wachsender Wartezeit. Das überbrückt kurze Unterbrechungen: Der Flow wartet an dem Objekt, bis alle Versuche abgeschlossen sind, und das Flow-Timeout begrenzt die Summe aus Versuchen und Wartezeiten. Das Handbuch warnt, die Wiederholung nur für Flows zu verwenden, die mehrfach ausgeführt werden dürfen, sonst drohen doppelte Schreibvorgänge. Für die synchrone Hälfte, die keinen Zwischenspeicher hat, ist das zugleich das definierte Verhalten im Fehlerfall: Schlägt der Aufruf endgültig fehl, läuft der Flow mit einem Standardwert je Ausgang weiter, und zwei eigene Ausgänge melden den folgenden Schritten, dass es ein Ersatzwert war.

Ein grüner Verbindungstest beweist wenig

Fehlen dem technischen Benutzer Berechtigungen, scheitert nicht der Verbindungsaufbau, sondern erst der Zugriff auf einzelne Funktionen und Tabellen. Das zeigt sich dann im laufenden Betrieb, an einem bestimmten Vorgang, oft Wochen nach der Inbetriebnahme.

Die Ursache: Berechtigungen werden beim Zugriff geprüft, nicht bei der Anmeldung: S_RFC je Funktionsgruppe, die Rechte für Tabellen und Buchungen erst in der aufgerufenen Funktion. Ein Verbindungstest prüft deshalb nur den Log-on.

Im Betrieb: Die Anbindung läuft im Testsystem, in der Produktion aber nicht, weil die Rolle dort enger geschnitten ist. Der Fehler tritt beim ersten Auftrag auf, der eine bisher unbenutzte Funktion braucht.

Was beim Betrieb liegt: Hier nimmt die Software am wenigsten ab. Die Rolle für den technischen Benutzer wird im SAP-System gebaut und muss in Test und Produktion gleich geschnitten sein. Dazu kommen kundeneigene Funktionsbausteine, die SAP-Bibliotheken, gesicherte Kommunikation über SNC und offene Ports (siehe Checkliste).

Im OPC Router: Die Prüfung selbst bleibt im SAP-System. Der OPC Router nimmt das Suchen ab: Die benötigten Berechtigungsobjekte stehen namentlich im Handbuch und lassen sich vor dem Projekt bestellen, statt sie im Betrieb nachzureichen. Mehr als der Verbindungstest prüft ein Handgriff: Wird nach dem Veröffentlichen jeder lesende Flow einmal von Hand ausgelöst, ohne Trigger, ist seine Funktionsgruppe angesprochen, bevor der erste Auftrag sie braucht. Buchende Flows buchen dabei tatsächlich; bei ihnen prüft ein lesender Aufruf derselben Funktionsgruppe nur S_RFC, nicht die Rechte der Buchung selbst.

Die Frage gehört schon in die Auswahl. Eine Fertigung steht nicht still, weil ein Server neu startet, und die Daten dieser Minuten dürfen nicht fehlen.

Ein verbreiteter Weg ist, Meldungen zwischenzuspeichern. Im OPC Router kann das auf der SAP-Strecke das Add-on Store & Forward sein, eine Datenbanktabelle, die der Transferstatus-Trigger abarbeitet (Wiederholung einschaltbar), oder beim IDoc-Versand die IDoc-Queue für nicht versendbare IDocs (siehe Checkliste oben). Ein Motorgerätehersteller geht einen Schritt weiter und bindet jede Montagelinie über den OPC Router an einen eigenen lokalen SQL-Server an. Der Anwenderbericht von April 2019 zählt 16 Installationen allein in Deutschland, dazu die Werke in den USA und China. Alle Informationen zu Teilen, Stücklisten und Produktionszeiträumen liegen dort lange vor Auftragsstart bereit. Die Folge nennt der Bericht ausdrücklich: Bei einem Verbindungsausfall lassen sich der laufende und der folgende Auftrag noch fertigen.

Die zweite Frage: Welches System ist Master? Wenn ERP und MES denselben Auftragsstatus führen, muss festliegen, welcher gilt. Diese Festlegung liegt beim Unternehmen und gehört vor die erste Zeile Konfiguration.

Die folgenden Zahlen stammen aus veröffentlichten Anwenderberichten und beschreiben den Ausbaustand zum Zeitpunkt der Veröffentlichung, nicht den von heute.

Ein Haftmaterial-Hersteller koppelt laut Anwenderbericht 14 Maschinen über 35 Verbindungen direkt zwischen SPS-Steuerungen und SAP (Stand des Berichts: undatiert, seine Firmenangaben beziehen sich auf das Geschäftsjahr 2017). Verbuchungszeiten liegen unter 15 Millisekunden bei rund 15.000 Datentelegrammen pro Tag. Das ERP sendet Rezepturen und Geschwindigkeiten, die Maschine meldet Fehlstellen und Qualitätsdaten zurück. Die Rückmeldung ist dabei Teil des Aufbaus: Die Kommunikation mit SAP ist zusätzlich über RFC mit Handshake abgesichert, und an der Meldung über den erfolgten Transfer fällt eine Unterbrechung auf. Ein MES liegt hier nicht dazwischen.

Ein Verpackungshersteller betreibt laut Anwenderbericht auf kepware-opcserver.de vom April 2020 rund 500 Maschinen in elf Werken. Ein OPC Server holt die Daten an den Maschinen, ein OPC Router im Headquarter bringt sie weiter, und das MES läuft auf einer eigenen SAP-Datenbank. Vom Holen bis zum Bereitstellen vergehen ein bis zwei Sekunden, das Datenvolumen liegt bei rund 1,2 Gigabyte pro Tag. Wo früher ein Betriebsdatensystem die Werte über Nacht auswertete, wurde nach dem Bericht jede Sekunde abgefragt. Maschinenanbindung, Datenvermittlung und MES sind in diesem Aufbau drei getrennte Systeme.

Bei einem italienischen Hersteller von Polyethylenrohren arbeitet der OPC Router nach der undatierten Sammlung internationaler Anwendungsfälle auf opc-router.de als Schicht zwischen SAP S/4HANA und einem MES, über SAP IDoc, SAP RFC und MS SQL Server. Konfiguriert sind mehrere Transaktionen in beide Richtungen, von Artikelstammdaten über Rohmaterialeingang und Produktionsaufträge bis zur Rückmeldung von produzierten Stücken, Materialverbrauch und Ausschuss in Kilogramm.

Ein Traditionsunternehmen für Spezialchemikalien hat an der Abfüllanlage diese Rückmeldung automatisiert. Vorher meldete ein Mitarbeiter die Anzahl der Gebinde von Hand ins System und klebte das Etikett selbst auf. Nach der Umstellung liest der OPC Router die Anzahl und die Prozessauftragsnummer aus der SPS und bucht die Menge per RFC in SAP zu; SAP erzeugt daraufhin das Etikett, das maschinell aufgebracht wird. Die vollständige Meldung geht an die SPS zurück und zusätzlich in eine SQL-Datenbank für die Rückverfolgung. Nach der Beschreibung ist das ein Fall aus der synchronen Hälfte: Das Etikett entsteht erst nach der Buchung in SAP. Die Anlage ging am 1. Mai 2019 in Betrieb, vorausgegangen war eine Testphase von rund vier Monaten.

Ein Hersteller von Wachstechnologien zeigt, wie eine Anbindung aussieht, die als Programmierprojekt entstanden ist. Laut Anwenderbericht auf opc-router.de über den Systemintegrator ZewaTec (Stand der Seite: Januar 2025) verband die erste Lösung zwei Siemens-Systeme und ein Yokogawa-Leitsystem über einen Verbund vieler Teillösungen mit SAP und brauchte dafür rund 20.000 Zeilen Code. Der Bericht nennt zwei Schwächen: die Kosten der vielen Softwarelizenzen und einen Datentransfer, der stockte, sobald eine der Teillösungen ausfiel. Der OPC Router löste danach über 90 Prozent dieser Programmierung durch grafische Verbindungen ab.