In einem automatisierten Hochregallager ist ständig etwas in Bewegung: Ein Werkstückträger fährt auf ein Förderband, eine Lichtschranke erkennt ihn, ein Regalbediengerät hebt ihn an und verstaut ihn in einem freien Fach. Wer aber entscheidet, in welches Fach er kommt – und wer merkt sich anschließend, wo er steht?
Die Antwort ist SAP Extended Warehouse Management (SAP EWM). SAP EWM ist die Denkzentrale des Lagers, die Bestände verwaltet und Einlagerentscheidungen trifft. Die Anlage selbst – Förderband, Regalbediengerät, Sensorik, gesteuert von einer speicherprogrammierbaren Steuerung (SPS) – ist die Muskulatur, die diese Entscheidungen ausführt. Die eigentliche Herausforderung liegt dazwischen: Wie lässt man eine physische Anlage im Werk zuverlässig mit einem SAP-System sprechen, das zunehmend in der Cloud betrieben wird?
Die Firewall zwischen Werk und Cloud
Eine SPS besitzt fast immer eine private IP-Adresse, die außerhalb des lokalen Netzwerks nicht erreichbar ist, und sie verhält sich passiv: Sie öffnet einen Port und wartet auf eingehende Verbindungen, ruft aber selbst niemanden an. Dazu kommt die Firewall, die im Werk fast immer nach derselben Regel arbeitet: Verbindungen von innen nach außen sind erlaubt, Verbindungen von außen nach innen werden blockiert. Ein SAP-System, das aus der Cloud direkt auf die Steuerung zugreifen will, scheitert deshalb doppelt – es findet die private Adresse nicht, und selbst wenn, würde die Firewall die eingehende Verbindung stoppen.
Für dieses Problem bietet SAP zwei Kommunikationswege. ABAP Push Channels (APC) sind direkt in SAP EWM integriert: Das System baut die Verbindung zur Steuerung selbst auf, ohne zusätzliche Middleware. Das ist schlank und funktioniert gut, solange SAP EWM die Steuerung direkt erreichen kann. SAP Plant Connectivity (PCo) geht den umgekehrten Weg: Diese Middleware läuft als eigener Agent im lokalen Werksnetzwerk, verbindet sich dort mit der Steuerung und meldet sich anschließend selbst aktiv beim SAP-Gateway an – von innen nach außen, wodurch die Firewall passiert wird. Für ein cloudbasiertes SAP EWM mit einer Steuerung im geschützten Werksnetzwerk ist PCo deshalb architektonisch der einzige gangbare Weg; sitzen EWM und Steuerung im selben, direkt erreichbaren Netzwerk, ist APC die einfachere Lösung.
Wie SAP EWM die Anlage steuert: das Materialflusssystem
Innerhalb von SAP EWM übernimmt das Materialflusssystem (MFS) die eigentliche Steuerungslogik. Es zerlegt eine Lageraufgabe in einzelne Etappen, denn zwischen Wareneingang und Lagerfach liegen oft ein Förderband, ein Scanner und ein Regalbediengerät – lauter Stationen, an denen jeweils eine Entscheidung fällt, die die Anlage selbst nicht treffen kann. An jeder dieser Etappengrenzen, den sogenannten Meldepunkten, tauschen SAP EWM und die Steuerung ein fest strukturiertes Telegramm aus: Die Anlage meldet, was passiert ist, SAP EWM entscheidet und teilt mit, was als Nächstes zu tun ist. Bewusst wird dabei nur an wirklich entscheidungsrelevanten Punkten ein Meldepunkt angelegt – alles dazwischen überlässt SAP EWM vollständig der Steuerung.
Bemerkenswert ist, wie granular diese Übersetzung am Ende wird: Eine Anweisung wie „Lagere in Fach 5 ein“ kennt die Anlage gar nicht als Adresse, sondern nur als Zahlenpaar aus Encoder-Impulsen ihrer Antriebsachsen. SAP EWM denkt in Lagerplätzen, die Steuerung denkt in Zählerständen – und genau diese Übersetzung leisten Meldepunkt und Telegramm gemeinsam.
Erst simulieren, dann real testen
Eine solche Anbindung testet man nicht in einem großen Schritt. Zuerst prüft SAP EWM seine eigene Logik ganz ohne Steuerung, indem es sich Telegramme selbst zuspielt. Danach folgt ein Test gegen eine simulierte Steuerung, um die Kommunikationsschicht und die Telegrammstruktur zu verifizieren, ohne die reale Anlage zu riskieren. Erst wenn beide Stufen fehlerfrei laufen, folgt der Test mit der physischen Anlage – inklusive gezielt provozierter Störungen, damit auch die Fehlerbehandlung sitzt.
Was Sie daraus mitnehmen
Hinter jeder Anbindung einer automatisierten Anlage an SAP EWM steckt im Kern ein einziger Satz: Die Maschine muss SAP mitteilen, was passiert ist, und SAP muss der Maschine mitteilen, was als Nächstes zu tun ist. Ob dieser Dialog gelingt, entscheidet sich an der Wahl der richtigen Kommunikationsbrücke für die eigene Netzwerksituation, an einer schlanken Konfiguration mit möglichst wenigen, aber richtig platzierten Meldepunkten und an einem gestuften Testvorgehen. Wer tiefer in den SAP-Standard im Extended Warehouse Management einsteigen möchte, findet dazu mehr in unserem Blog. Was sich an einem kompakten Modell zeigen lässt, gilt im Kern genauso für reale Distributionszentren – nur die Dimensionen wachsen.
Dieser Beitrag gibt einen fachlichen Überblick über die grundsätzliche Architektur einer solchen Anbindung. Für die Umsetzung in einem konkreten Projekt sollte der Entwurf vor der praktischen Anwendung fachlich geprüft und an die jeweilige Systemlandschaft angepasst werden.