Telegrammmonitoring in SAP EWM MFS: Retry, CP Channels, Queue-Staus und Debugging in der Praxis

Warum „Telegrammmonitoring“ in MFS-Projekten über Stabilität entscheidet

In SAP EWM MFS ist die Telegrammkommunikation kein „Interface-Detail“, sondern der operative Taktgeber zwischen SAP und der unterlagerten Steuerung (SPS/PLC). Wenn der Materialfluss stockt, HU-Positionen „springen“ oder Durchsatz einbricht, ist die Ursache in der Praxis sehr häufig nicht die Businesslogik (z. B. Putaway-Strategie), sondern eine Störung in Kanalzustand, Handshake, Retry, Queue-Serialisierung oder Telegrammverarbeitung.

Telegrammmonitoring ist deshalb keine reine IT-Disziplin, sondern Teil der Betriebsfähigkeit: Es verbindet technische Signale (Timeouts, Buffer, Kanal-Synchronisation) mit fachlichen Objekten (WT/WO/HU) und macht Fehlerbilder reproduzierbar – die Voraussetzung für belastbares Debugging und stabile Hypercare.

Eine Einordnung der Materialflusssteuerung im Automatisierungs-Stack finden Sie auf unserer Leistungsseite SAP EWM Materialflusssteuerung.

Aufbau der Telegrammkommunikation: Von TCP/IP-Stream bis zur MFS-Verarbeitung

Transport: TCP/IP, Socket/Stream und der „Communication Channel“

SAP EWM MFS kommuniziert mit einer SPS/PLC über TCP/IP und nutzt dafür Kommunikationskanäle („Channels“), die über Host/IP und Port beschrieben sind. Entscheidend ist: TCP/IP ist in diesem Kontext typischerweise stream-orientiert – es gibt keine garantierten Nachrichtengrenzen. Genau deshalb sind Mechanismen wie fixe Telegrammlängen, Delimiter oder Header-Längenfelder in der Praxis so wichtig.

Protokollebene: Datentelegramm vs. Acknowledgement (Handshake)

Auf Protokollebene unterscheidet MFS zwischen Datentelegrammen (tragen Nutzdaten, die verarbeitet werden sollen) und Acknowledgement-Telegrammen (Quittierung bzw. Annahme-/Ablehnungsreaktion auf Protokollebene). Diese Unterscheidung ist zentral für Retry-Mechanismen und für die Diagnose „verloren“ vs. „doppelt“.

Verarbeitung in SAP: Empfang, Parsing, Mapping, Folgeaktionen

Für den Empfang und die Verarbeitung eingehender Telegramme wird in SAP EWM MFS eine Standardlogik genutzt (z. B. über ein Empfangs-Funktionsmodul), die den Kanal/PLC kontextualisiert, Telegramme formatiert und den Inhalt in eine Gesamtstruktur überführt, aus der anschließend Telegrammtyp/Struktur abgeleitet und verarbeitet wird. Wenn Header oder Struktur nicht eindeutig ermittelt werden können, entstehen Fehlerfälle, die typischerweise nicht als „falscher Businessprozess“, sondern als Verarbeitungsfehler im Kommunikationspfad sichtbar werden.

Telegrammtypen: Welche Klassen man im Monitoring unterscheiden muss

In realen Projekten variieren die konkreten Telegrammfamilien (OEM-/Subsystem-spezifisch). Für Monitoring und Debugging ist jedoch eine robuste Klassifizierung nach funktionaler Wirkung entscheidend:

SPS-Kommunikation & CP Channels: Was „Synchronisation“ wirklich bedeutet

Ein häufiger Denkfehler im Betrieb ist: „Kanal ist up, also läuft die Kommunikation.“ In MFS ist der Kanalzustand nur ein Teil. Für stabile Verarbeitung müssen Channels synchronisiert sein. Synchronisation bedeutet in diesem Kontext: Nach Verbindungsaufbau konnte die SPS alle während der Trennung aufgelaufenen Meldungen senden; der Sendepuffer der SPS ist leer, und jedes gesendete Telegramm wird von der SPS quittiert, bevor EWM es als gesendet verbucht.

Betrieblich relevant:

• Solange der Kanal synchronisiert ist, sendet EWM automatisch Telegramme.
• Bleibt die Quittierung aus, greift der Wiederholmechanismus (Retry).
• Findet gar keine Kommunikation statt, startet EWM eine Kanalprüfung per Life-Telegramm (Intervall konfigurierbar).

Queue-Verarbeitung: Warum Telegrammstau fast immer ein Queue-/Serialisierungsproblem ist

Queue-Findung und Serialisierung

MFS nutzt Queues, um die Verarbeitung zu serialisieren und die Zuständigkeit (z. B. für Ressourcen/Anlagenbereiche) zu steuern. Die Queue-Logik beeinflusst direkt, ob Telegramme in der erwarteten Reihenfolge erzeugt und verarbeitet werden und ob Parallelität sinnvoll genutzt wird.

KZSUB/„Sendestatus“ als Diagnosehebel

Im operativen Monitoring ist ein wesentliches Signal, ob ein WT „subsystem-relevant“ ist und ob er bereits an das Subsystem gesendet wurde bzw. gesendet werden kann. Diese Statuslogik ist in MFS-Betriebssichten typischerweise sichtbar und wird in Projekten auch genutzt, um gezielt einen Resend zu ermöglichen.

Typische Ursachen für Queue-Staus

• Downstream-Blockade: SPS/Anlage quittiert nicht oder langsam ⇒ Queue wächst.
• Fehlende Parallelität: zu grobe Queue-Zuschnitte, alles in einer Serialisierung.
• Race/Out-of-Order: konkurrierende Flüsse, die logisch getrennt, aber technisch gemeinsam serialisiert werden. (Diagnostisch sichtbar über Telegrammreihenfolge und Buffer-Wachstum).

Retry-Mechanismen: Wie man „verloren“ vs. „doppelt“ sauber trennt

EWM wiederholt nicht bestätigte Telegramme automatisch nach einem am Kanal konfigurierbaren Intervall.

Das ist fachlich korrekt – führt aber zu typischen Missverständnissen:

• „Doppelte Telegramme“ sind häufig Retries, weil ein ACK verspätet kam.
• Ein robustes System muss Retries idempotent behandeln (die Quittierungslogik muss erkennen: „das kenne ich bereits“).
• Ein hoher Retry-Anteil ist ein Frühindikator für Probleme in Kanalqualität, PLC-Last oder Verarbeitungszeit in SAP.

Monitoring-Transaktionen & operative Sicht: Was im Leitstand wirklich zählt

Zentrale Drehscheibe: Warehouse Monitor

Im MFS-Betrieb wird typischerweise der Warehouse Monitor als zentrale Sicht genutzt. Dort sind u. a. folgende Monitoring-Objekte relevant:

• Status der Kommunikationskanäle
• Status/Konfiguration der Communication Points
• Telegram Log
• Überblick HUs auf Fördertechnik
• offene MFS-relevante Warehouse Tasks
• Ressourcenstatus (z. B. SRMs)
• Incoming/Outgoing Telegram Buffer

Operative MFS-Pflege-/Analyse-Transaktionen

Für Support/Hypercare braucht man neben Monitoring auch Pflege-/Analysezugriff auf MFS-Objekte (z. B. Kommunikationspunkte, PLC-Objekte, Channels, Ressourcen, Objektmapping, Log-Bereinigung). In realen Projekten wird das über dedizierte Rollen und MFS-Transaktionen abgedeckt.

Logging: Was man loggen muss (und wie man Logs „schichttauglich“ macht)

Ein Telegramm-Log ist nur dann betrieblich wertvoll, wenn es den Sprung von „Rohdaten“ zu „diagnosefähiger Information“ schafft. In der Praxis bewährt sich:

• Kontextfelder (z. B. Area, Anlage/Subsystem-ID, CP-Gruppen) in der Log-Sicht
• strukturiertes Feld-Rendering je Telegrammtyp (nicht jede Zeile ist gleich)
• Farbliche Hervorhebung relevanter Felder je Typ
• Detailansicht „Telegram Content View“ für schnelle Interpretation im Leitstand

Das Ziel ist klar: Ein Schichtleiter muss in Sekunden sehen können, wer gesendet hat, was gesendet wurde, ob quittiert wurde, welches Objekt betroffen ist und wo der Prozess hängt.

Performance-Aspekte: Latenz ist kein Nice-to-have, sondern Materialfluss

Performance-Probleme äußern sich im MFS-Umfeld sehr direkt als:

• verzögerte Telegrammverarbeitung
• steigende Queue-Längen
• wachsende Buffer
• sinkender Durchsatz, weil die Anlage „auf SAP wartet“

Typische technische Ursachen sind:

• unzureichende Parallelität bei Telegrammverarbeitung
• langsame Action-Processing-Logik
• ungünstige MFS-Prozesseinstellungen/Mapping

Konsequenz für Monitoring: Sie benötigen nicht nur „Fehler-Monitoring“, sondern auch KPI-Monitoring (Telegramm-Response, Retry-Rate, Buffer-Trend, Queue-Trend).

Typische Fehlerbilder: Symptome → Ursachen → Debugging-Ansatz

Go-Live-Support & Hypercare: Operative Überwachung als eigenes Setup

Für MFS-Go-Lives gilt: Stabilität entsteht nicht durch „mehr Leute“, sondern durch klare Betriebsinstrumente:

• vorkonfigurierte Monitor-Sichten (pro Area/Anlage)
• definierte Alarm-/Schwellwerte (Retry-Rate, Buffer-Wachstum, Kanal-Synchronisation)
• Runbooks: „Wenn X, dann prüfe Y“
• klare Eskalationslogik zwischen SAP-Team und SPS-Team

Hypercare ist dann effizient, wenn die wichtigsten Debug-Fragen in Minuten beantwortbar sind:

• hängt es am Channel?
• hängt es am ACK/Retry?
• hängt es an Queue/Serialisierung?
• hängt es an einer MFS-Action/Exception-Folge?

Debugging-Playbook

Wie wir Telegrammverarbeitung und reproduzierbare Tests per Simulation in SAP EWM MFS unterstützen, erfahren Sie auf der Seite Qinlox Toolbox für SAP EWM MFS.