Ein Termin, über den im Mittelstand kaum jemand spricht
Die Mainstream-Wartung für SAP Manufacturing Execution (ME) und SAP Manufacturing Integration and Intelligence (MII) endet zum 31. Dezember 2027. Wer länger braucht, kann kostenpflichtige Extended Maintenance bis Ende 2030 hinzukaufen. Die Verlängerung auf 2030 geht auf die DSAG zurück; ursprünglich war 2027 der harte Termin. Deshalb kursieren bis heute beide Jahreszahlen — und in der Product Availability Matrix von SAP stand zeitweise weiterhin 2027.
Der offizielle Nachfolger ist SAP Digital Manufacturing, eine reine Cloud-Lösung auf der Business Technology Platform. Für Konzerne mit eigener SAP-Mannschaft ist das ein Projekt mit Lastenheft, Steuerungskreis und einem Zeitraum von zwölf bis vierundzwanzig Monaten pro komplexem Werk.
Für ein Werk mit zwanzig bis fünfzig Maschinen stellt sich eine andere Frage — eine, die selten offen gerechnet wird: Rechnet sich diese Migration überhaupt? Und für Betriebe, die nie ein SAP-MES hatten, weil ME immer zu teuer war, stellt sich die Frage in noch schärferer Form. Für sie ist Digital Manufacturing genauso wenig eine Antwort, wie ME es je war.
Der folgende Aufbau ist die Antwort, die ich für diese Größenordnung für richtig halte.
Warum die Datenerfassung nicht am ERP hängen darf
Der verbreitete Denkfehler bei Cloud-MES beginnt bei der Frage, wo die Betriebsdatenerfassung eigentlich stattfindet. Wenn das Terminal an der Linie mit einem System in der Cloud spricht, hängt die Produktionsrückmeldung an der Internetleitung. Fällt sie aus, steht das Terminal. Die Maschine läuft weiter, aber niemand zählt mit.
Eine Erfassung, die im Werk stattfindet und erst danach ins ERP bucht, kennt dieses Problem nicht. Die Trennung kostet etwas Architektur, spart aber eine ganze Klasse von Störungen — und sie ist die Voraussetzung dafür, dass Maschinentakte im Millisekundenbereich überhaupt sinnvoll verarbeitet werden können.
Der Aufbau in vier Ebenen
1. OT- und Maschinenebene
Die Maschine liefert ausschließlich Rohdaten: den Zyklusimpuls, den Status der Signalampel, gegebenenfalls Sensorwerte wie Temperaturen oder Drücke. Moderne Steuerungen geben das über OPC UA heraus, ältere über Modbus TCP oder als diskrete 24-Volt-Signale über dezentrale I/O-Module oder eine Kleinsteuerung.
Entscheidend ist das Prinzip dahinter: keine ERP-Logik auf Maschinenebene. Die Steuerung kennt keine Auftragsnummern und muss sie nicht kennen. Damit bleibt sie von jeder Änderung im ERP unberührt.
2. Edge-Gateway im Maschinennetz
Das Gateway sammelt die Signale ein und macht daraus verwertbare Information. Es entprellt die Takte, plausibilisiert Zykluszeiten und erkennt Stillstände eigenständig: Kommt über eine definierte Zeitspanne kein Zyklusimpuls, wechselt der Status auf ungeplanten Stillstand — ohne dass ein übergeordnetes System dafür befragt werden muss.
Alle Rohimpulse und Statuswechsel landen zunächst in einer lokalen Datenbank. Für reine Taktdaten genügt SQLite mit erheblicher Reserve: Zehn Maschinen mit drei Sekunden Zykluszeit erzeugen gut drei Ereignisse pro Sekunde. Interessant wird eine Zeitreihendatenbank wie TimescaleDB erst, wenn Prozessdaten dazukommen — Werkzeuginnendruck, Heizzonen, Einspritzprofile. Dann zählen weniger die Schreibraten als die Retention- und Compression-Policies und die vorberechneten Aggregate.
Der wichtigste Punkt an dieser Ebene ist ihre Universalität. Das Gateway übersetzt jede Anlage auf ein gemeinsames Datenmodell, unabhängig von Hersteller, Baujahr und Verfahren. Spritzguss, Stanzen, Umformen oder Montage laufen im selben Modell. Ob eine Maschine über OPC UA spricht oder über einen potentialfreien Kontakt am Schaltschrank, ist danach nicht mehr zu unterscheiden. Ein Zyklus ist ein Zyklus.
Das hat eine betriebswirtschaftliche Folge: Ein gemischter Maschinenpark aus vier Jahrzehnten kostet keine zwölf Integrationen, sondern zwölf Konfigurationen. Und eine neue Anlage im nächsten Jahr bedeutet einen zusätzlichen Adapter unten, nicht einen Eingriff oben.
3. Werker-Interaktion am BDE-Terminal
Die Terminals an der Linie sind schlanke Web-Oberflächen auf Kiosk-Touchscreens. Sie sprechen mit dem Werksnetz, nicht mit dem Internet. Der Werker wählt den lokal gepufferten Fertigungsauftrag, Gutmenge und Takt laufen über die Maschinensignale automatisch auf. Bei einem Stillstand öffnet sich ein Meldedialog mit hinterlegten Gründen, Ausschuss wird per Schaltfläche mit Grund erfasst.
Masken, Störgründe und Ausschussgründe werden je Betrieb festgelegt. Ein Spritzgussbetrieb braucht andere Kategorien als eine Stanzerei, und eine Erfassung, die nicht zur Sprache der Werker passt, wird nicht benutzt.
4. Integrations- und Verdichtungsschicht
Erst hier entsteht die Verbindung zum ERP. Das ERP braucht keinen einzelnen Maschinentakt, sondern kaufmännisch verwertbare Pakete. Die Verdichtung erfolgt zeitgesteuert in kurzen Intervallen oder ereignisbezogen bei Auftragsende und Schichtwechsel.
Die fertige Buchung geht in eine Ausgangswarteschlange mit dem Status PENDING. Ein Worker sendet sie an das ERP und setzt bei bestätigter Verbuchung auf CONFIRMED. Schlägt die Verbindung fehl, greift ein exponentieller Backoff: erster Wiederholversuch nach Sekunden, dann in wachsenden Abständen bis zu einer Obergrenze. Die Produktion läuft davon unbeeindruckt weiter.
Die drei Stellen, an denen solche Projekte scheitern
Idempotenz
Der gefährlichste Fall ist nicht der klare Fehler, sondern das Timeout. Das ERP verbucht 1250 Gutstück korrekt, die Antwort geht auf dem Rückweg verloren, der Retry schickt dieselbe Buchung erneut. Ohne Schutz stehen anschließend 2500 Stück im System, mit doppeltem Materialverbrauch und falscher Nachkalkulation. Weil das nur bei Netzproblemen auftritt, fällt es im Test nie auf, sondern erst im Produktivbetrieb.
Die Absicherung ist ein selbst erzeugter Schlüssel pro Buchungspaket, der beim ersten Versuch vergeben und bei jeder Wiederholung unverändert mitgeschickt wird. Entweder lehnt das Zielsystem einen bekannten Schlüssel selbst ab, oder der Worker prüft vor jedem Wiederholversuch, ob eine Buchung mit diesem Schlüssel bereits existiert. Ein Retry-Mechanismus ohne Idempotenz ist eine Maschine zur Erzeugung von Doppelbuchungen.
Ebenso wichtig ist die Unterscheidung der Fehlerarten. Ein Netzfehler oder ein Serverfehler ist wiederholbar. Eine fachliche Ablehnung — der Vorgang ist bereits abgeschlossen, die Menge überschreitet den Sollwert — ist es nicht. Solche Sätze gehören in einen Fehlerzustand und auf einen Bildschirm, den jemand ansieht.
Der Weg nach unten
Über den Rückweg wird viel gesprochen, über den Hinweg selten. Damit der Werker einen lokal gepufferten Auftrag auswählen kann, müssen Auftragsköpfe, Vorgänge, Sollmengen und Arbeitsplatzzuordnungen erst einmal ankommen — inklusive Statusänderungen. Wenn das ERP zwei Stunden nicht erreichbar war und der Auftrag zwischenzeitlich technisch abgeschlossen wurde, würde sonst gegen einen toten Vorgang gebucht. Praktisch heißt das: regelmäßiger Delta-Abgleich plus Gültigkeitsprüfung unmittelbar vor dem Senden aus der Warteschlange.
Lizenzen
Bei SAP-Systemen kann eine schreibende Rückmeldung über eine API unter Digital Access fallen, und der Fertigungsauftrag gehört zu den lizenzrelevanten Dokumententypen. Das spricht nicht gegen die Architektur — im Gegenteil, es ist ein weiteres Argument für die Verdichtung. Aber es gehört früh auf den Tisch, statt im Lizenzaudit aufzutauchen.
Zonentrennung nach IEC 62443
Eine Erfassung, die alle Netze berührt, ist ohne Segmentierung ein Risiko. Der Aufbau folgt deshalb dem Zonen- und Conduit-Modell:
Zone Maschinennetz. Kein Gateway, kein Internet. Darin steht ausschließlich das Edge-Gateway. Es baut Verbindungen nur ausgehend auf und nimmt keine eingehenden Anfragen entgegen — auch nicht aus dem eigenen Werksnetz.
Zone Werksnetz. Hier liegen Broker, Zeitreihendatenbank, Verdichtungsschicht und die BDE-Terminals. MQTT ausschließlich über TLS, jeder Client mit eigenem Zertifikat und beschränkt auf seine Topics. Ein kompromittiertes Terminal sieht keine fremden Maschinendaten. Segmentierung allein genügt nicht; innerhalb der Zone braucht es Authentifizierung und Autorisierung.
Conduit zum ERP. Die einzige Verbindung nach außen. Fällt sie aus, puffert die Warteschlange im Werk, und die Erfassung an der Linie läuft unverändert weiter.
Conduit für die Fernwartung. Kein Sonderzugang, sondern ein definierter Weg: Jump-Host, temporär freigeschaltet, Session protokolliert, sonst getrennt. Kein externer Techniker bekommt eine Dauerverbindung ins Maschinennetz.
Unabhängig vom ERP
Die Ebenen eins bis drei wissen nicht, welches System am Ende bucht. Austauschbar ist allein die Verdichtungsschicht — vorausgesetzt, sie arbeitet mit einem kanonischen Zwischenmodell: Auftrag, Vorgang, Gutmenge, Ausschuss mit Grund, Start- und Endzeitpunkt, Ressource, optional Person. Alles darüber ist ein Mapper je Zielsystem.
Der Aufwand fällt unterschiedlich aus. Systeme mit dokumentierter REST- oder OData-Schnittstelle und einer echten Vorgangsebene sind in wenigen Tagen angebunden. Bei SAP ist nicht die Technik der Engpass, sondern Berechtigungen und Customizing beim Kunden. Und im Mittelstand trifft man regelmäßig auf ältere Fertigungssoftware ohne brauchbare API — für diese Fälle sollte ein Dateiadapter von vornherein als vollwertiger Weg vorgesehen sein, nicht als Notlösung. Ein überwachtes Verzeichnis mit Quittungsdatei nimmt fast jedes System an.
Wichtig ist die Richtung der Abbildung: Das kanonische Modell bildet die reichste Variante ab, der Mapper reduziert beim Ziel. Nicht alle Systeme kennen eine Vorgangsebene, nicht alle haben strukturierte Ausschussgründe, und Storno sowie Teilrückmeldung sind fast überall unterschiedlich gelöst.
Was das für Brownfield bedeutet
Der Satz, eine Maschine sei nicht anbindbar, stimmt fast nie. Er bedeutet meistens, dass sie kein modernes Protokoll spricht. Für die Taktzählung genügt aber ein potentialfreier Kontakt aus der Maschinensteuerung, bei Spritzgießmaschinen häufig über die Handling-Schnittstelle nach Euromap 12 oder 67, bei sehr alten Anlagen direkt vom Endschalter oder aus einem freien Relaiskontakt im Schaltschrank. Eine Kleinsteuerung wie eine Siemens LOGO! reicht aus, um daraus ein verlässliches digitales Signal zu machen.
Eine Anlage von 1997 liefert damit dieselbe Datenqualität für OEE-Betrachtungen wie eine aktuelle Maschine mit OPC-UA-Server. Der Unterschied liegt nur im Detailgrad der Prozessdaten, nicht in der Verwertbarkeit der Takt- und Stillstandsdaten.
Fazit
Das Wartungsende von SAP ME und MII zwingt Konzerne zu einer Migrationsentscheidung. Für Werke mit zwanzig bis fünfzig Maschinen ist die interessantere Erkenntnis eine andere: Fertigungsdatenerfassung braucht kein Konzern-MES. Sie braucht eine saubere Trennung zwischen Signalerfassung, lokaler Verarbeitung und kaufmännischer Buchung — und die Disziplin, an den drei kritischen Stellen sorgfältig zu arbeiten.
Wer vor derselben Frage steht, kann mich gern darauf ansprechen.