Die wichtigsten Erkenntnisse im Überblick
Lagerungssteuerung und Routing für Behälterfördertechnik beantworten dieselbe Frage: Wohin soll die Handling Unit als Nächstes? Dieser Beitrag zeigt Grundmechanik, Customizing, Praxisabläufe und Grenzen beider Logiken und erklärt, woran sich die Wahl im Blueprint orientieren sollte.
Die Schnittstelle entscheidet, nicht das Fördergut
Welche Routing-Logik passt, ergibt sich aus der Telegrammschnittstelle und der Aufgabenteilung zwischen EWM und SPS, nicht aus Palette oder Behälter.
Etappenkette oder Richtungsentscheidung
LOLS baut den Weg Etappe für Etappe über Lageraufgaben auf, das BFT-Routing entscheidet rein lesend an jedem Meldepunkt.
Beide Verfahren haben klare Grenzen
Alternativrouten und echte Wegefindung müssen in beiden Fällen selbst entwickelt werden, die BFT-Logik liefert dank Default aber immer eine Antwort.
1. Einleitung
Die layoutorientierte Lagerungssteuerung war zuerst da. Eingesetzt wurde sie überwiegend für Palettenfördertechnik, für Behälteranlagen gab es schlicht keine passende Lösung. Erst später kam das Routing für Behälterfördertechnik dazu.
Aus dieser Reihenfolge sind die Namen entstanden, und mit ihnen ein hartnäckiges Missverständnis. Das BFT-Routing funktioniert nämlich nicht nur für Behälteranlagen, es lässt sich genauso auf einer Palettenfördertechnik betreiben. Welche Logik am Ende zum Einsatz kommt, hängt davon ab, wie die Anlage ausgelegt und umgesetzt ist, und nicht davon, was auf dem Förderband liegt.
Ausschlaggebend ist die Aufgabenteilung zwischen EWM und speicherprogrammierbarer Steuerung. Wie kleinschrittig entscheidet EWM, und wie viel Wegfindung überlässt man der Anlage?
Die Entscheidung für eine Routing-Logik sollte deshalb nicht anhand des Förderguts getroffen werden, sondern anhand der Telegrammschnittstelle, der Meldepunktlogik und der Frage, wo die Wegfindung stattfinden soll.
Im Folgenden gehen wir beide Routing-Logiken durch: Grundmechanik, Customizing und die Stellen, an denen der Standard nicht mehr weiterhilft.
Einen Überblick über die Steuerung automatisierter Lagertechnik direkt aus SAP EWM finden Sie auf unserer Leistungsseite SAP EWM Materialflusssteuerung.
Nicht der Ladungsträger entscheidet über die Routing-Logik, sondern Design und Umsetzung der Anlage.
Die Lagerungssteuerung setzt voraus, dass die SPS einen Meldepunkt als Ziel versteht. Das BFT-Routing ist flexibler: Dort kann die logische Destination eine Richtung sein oder ebenfalls der nächste Meldepunkt.
2. Technische Grundlagen
Beide Verfahren beantworten dieselbe Frage, nämlich wohin die Handling Unit als Nächstes soll. Der Weg zur Antwort unterscheidet sich allerdings erheblich.
Gleiche Bausteine, völlig andere Logik
Beide Varianten sind meldepunktbasiert und arbeiten überwiegend mit denselben Objekten: Meldepunkte, Fördersegmente, SPS-Definition, Telegrammverarbeitung.
Unterschiedlich ist allein die Routing-Logik darüber.
2.1 Layoutorientierte Lagerungssteuerung (LOLS)
Die layoutorientierte Lagerungssteuerung greift immer dann, wenn eine Bewegung nicht direkt vom Von- zum Nachlagerplatz führen kann, sondern über einen Zwischenlagerplatz laufen muss. Klassisches Beispiel: Eine Palette soll ins Hochregal. Vorher steht aber die Konturen- und Gewichtskontrolle am Identifikationspunkt an, danach geht es auf den Übergabepunkt zum Regalbediengerät, und erst von dort auf den eigentlichen Lagerplatz im Hochregal.
Die Mechanik dahinter ist eine Kette:
- Die Lageraufgabe auf das eigentliche Ziel (A → D) wird inaktiv angelegt. Das Ziel bleibt also die ganze Zeit bekannt.
- Parallel entsteht eine offene Lageraufgabe zum nächsten Zwischenlagerplatz (A → B).
- Beim Quittieren auf B wird der Vonlagerplatz der inaktiven Lageraufgabe von A auf B geändert und erneut geprüft: Gibt es von hier aus einen weiteren Zwischenlagerplatz? Wenn ja, entsteht die nächste offene Lageraufgabe (B → C).
- Ist eine direkte Bewegung zum Ziel möglich, wird die inaktive Lageraufgabe aktiviert und läuft als letzte Etappe durch.
Der Weg entsteht damit nicht vorab, sondern Etappe für Etappe, jeweils beim Quittieren der vorherigen. Und noch eine Einschränkung: Ohne Handling Units läuft LOLS nicht.
Hinter einem Zwischenlagerplatz steckt dabei praktisch immer ein Meldepunkt, dem ein Lagerplatz zugeordnet ist. Wie weit eine Etappe reicht, ist damit aber noch nicht gesagt: Das nächste Zwischenziel muss weder die nächste Kreuzung noch der übernächste Meldepunkt sein. Wie groß die Sprünge ausfallen, hängt davon ab, wie viel Wegfindung in der Steuerung implementiert ist.
Ausweichoptionen gibt es, aber nur begrenzt. Über die Sequenznummer lassen sich mehrere Zwischenlagerplätze pflegen. Ist B belegt, kann B1 gefunden werden. Das gilt allerdings immer nur für den nächsten Schritt. C wird überhaupt erst geprüft, wenn C zum aktuell nächsten Zwischenlagerplatz wird. Eine vorausschauende Bewertung ganzer Routen findet im Standard nicht statt.
Gepflegt wird das an zwei Stellen im Customizing, die auf dieselbe Definition führen: unter Materialflusssystem (MFS) → Lagerungssteuerung bzw. unter Prozessübergreifende Einstellungen → Lageraufgabe.
Für Projekt- und Customizing-Teams relevant:
| Objekt | Typ | Bedeutung |
|---|---|---|
| /SCWM/V_TROUTL | Pflegeview | Layoutorientierte Lagerungssteuerung definieren |
| /SCWM/TROUTL | Tabelle | Von-/Nach-Kombination → Zwischenlagerplatz |
| /SCWM/TROUTLS | Tabelle | Lagerungsgruppen je Lagertyp |
| /SCWM/DE_VLBER_LGST | Datenelement | Von-Lagerungsgruppe |
| /SCWM/TROUTL_DET | Funktionsbaustein | Leselogik zur Laufzeit |
Der Aufbau von /SCWM/TROUTL erklärt die Mechanik von selbst: Als Selektion dienen Von-Lagertyp und Von-Lagerungsgruppe (VLTYP/VLBER) sowie Nach-Lagertyp und Nach-Lagerungsgruppe (NLTYP/NLBER) – also woher und wohin. Ergebnis ist der nächste Zwischenlagerplatz (ILTYP/ILBER/ILPLA). Über die Sequenznummer (SEQNR) lassen sich Alternativen hinterlegen. Einen kompletten Pfad kann die Tabelle nicht abbilden, ein Satz beschreibt immer nur einen Schritt.
2.2 Routing für Behälterfördertechnik
Eine Behälteranlage kennt von der HU meist nur den Barcode, und entschieden werden muss sofort, der Behälter wartet nicht. Also wird an jedem Meldepunkt anhand der HU-Attribute ermittelt, wohin es weitergeht. Links, rechts, geradeaus.
Drei Dinge sind dabei entscheidend:
- Es wird ausschließlich gelesen. Die Routing-Entscheidung selbst legt keine Lageraufgabe an und ändert keinen Status.
- Man fährt von Kreuzung zu Kreuzung. An die SPS wird in der Regel nur eine Richtung gesendet.
- Es gibt immer eine Antwort. Über den Default-Satz bekommt die SPS in jedem Fall eine Richtung, notfalls Richtung Klärplatz.
Als Kriterium dient entweder der Aktivitätsbereich, also das fachliche Ziel der HU, oder ihr Zustand im EWM: fehlerhaft, leer, ohne Auftrag. Passt keiner der gepflegten Sätze, greift der Vorschlagswert.
Technisch besteht das Routing aus drei Bausteinen, die zusammen als Übersetzungsschicht arbeiten. EWM denkt in Zuständen, die SPS kennt nur Ausgänge.
Für Projekt- und Customizing-Teams relevant:
| Objekt | Typ | Bedeutung |
|---|---|---|
| /SCWM/TMFSLD_E | Tabelle | Logische Destinationen EWM – fachliche Zustände der HU |
| /SCWM/TMFSROUTE | Tabelle | Routing-Definition: Meldepunkt + Kriterium → Richtung |
| /SCWM/TMFSLD_P | Tabelle | Logische Destinationen SPS – physische Ausgänge |
| /SCWM/MFSACT_CASE_ROUTE | Funktionsbaustein | Routing-Entscheidung zur Laufzeit |
Die eigentliche Routing-Definition in /SCWM/TMFSROUTE kombiniert SPS und Meldepunkt (PLC/CP) mit dem Selektionskriterium (LD_EWM oder AAREA) und liefert die Richtung (LD_PLC). Optional lässt sich ein Nach-Meldepunkt pflegen, auf den die HU gebucht wird. Die Bewegungsbuchung erfolgt dann entweder asynchron oder auf Basis des Ist-Routings, das die SPS an EWM zurückmeldet.
Woher der Aktivitätsbereich stammt, ist dabei offen: Er kann aus der Grobplatzermittlung kommen, ebenso gut aber aus einer bereits vorhandenen Produkt- oder HU-Lageraufgabe. Für die Routing-Entscheidung spielt das keine Rolle, gelesen wird nur das Ergebnis.
Anders als bei LOLS fehlt der Tabelle ein Sequenznummer-Feld. Alternative Routen für gesperrte oder blockierte Meldepunkte lassen sich im Standard also gar nicht hinterlegen.
2.3 Das eigentliche Unterscheidungskriterium
Statt „Paletten hier, Behälter da“ trifft es die Aufgabenteilung deutlich besser:
Die kürzeste Faustregel
Je mehr Logik in der Steuerung steckt, desto eher passt die Lagerungssteuerung – vorausgesetzt, die SPS versteht einen Meldepunkt als Ziel und findet die Zwischenwege selbst.
Je weniger die SPS kann, desto eher passt das BFT-Routing, weil EWM dann an jeder Verzweigung selbst entscheiden muss.
Das BFT-Routing kann beides: Als logische Destination lässt sich eine Richtung hinterlegen, genauso gut aber der nächste Meldepunkt.
| Routing für Behälterfördertechnik | Layoutorientierte Lagerungssteuerung | |
|---|---|---|
| Entscheidungsdichte | An jeder Kreuzung | Nur an relevanten Etappenpunkten |
| Reichweite je Entscheidung | Bis zur nächsten Kreuzung | Bis zum nächsten Etappenziel (A → D) |
| Eigenanteil der SPS | Minimal, fährt nur wohin gesagt | Hoch, findet Zwischenwege selbst |
| Inhalt der Destination | Richtung oder nächster Meldepunkt | Nur Meldepunkt / Zwischenlagerplatz |
| Datenwirkung | Nur lesend | Schreibend (LB anlegen, aktivieren) |
| Aufsetzen von Ladungsträgern | Praktisch überall möglich | Nur an definierten Punkten |
2.4 Customizing auf einen Blick
Im SPRO-Baum liegen beide Logiken unter demselben Knoten, aber in getrennten Ästen.
3. Einlagerung ins Automatiklager: Warum spätes Entscheiden funktioniert
Ein Sonderfall verdient ein eigenes Kapitel, weil er über reine Grundlagen hinausgeht: Wie die Behälterfördertechnik bei der Einlagerung ins Automatische Kleinteilelager arbeitet.
Wird über die Behälterfördertechnik in ein Automatiklager eingelagert, kann die Logik bereits im Standard eine Grobplatzermittlung durchführen, und die darf asynchron laufen. Der Ablauf entkoppelt Bewegung und Entscheidung:
- Scan am I-Punkt: Die HU wird identifiziert und fährt sofort weiter.
- Die Grobplatzermittlung läuft im Hintergrund. Die Anlage wartet nicht.
- Am nächsten Scanner wird anhand des Grobergebnisses bis zur Gasse geroutet.
- Erst unmittelbar vor dem Regalbediengerät wird das konkrete Ziel ermittelt und eine Lageraufgabe für die Ressource angelegt.
Entschieden wird also so spät wie möglich und zunächst nur so genau wie nötig. Bei LOLS ist es umgekehrt, dort steht das Ziel von Anfang an in der inaktiven Lageraufgabe. Eine Anlage, die bei jeder Einlagerung auf die vollständige Platzermittlung wartet, kommt bei Behältergeschwindigkeit nicht mit.
Wichtige Ausnahme
Ressourcen brauchen immer eine Lageraufgabe – unabhängig davon, ob BFT-Routing oder Lagerungssteuerung im Einsatz ist.
Auf der Strecke unterscheiden sich die Welten fundamental. An der Ressource laufen sie wieder zusammen.
Nicht jedes Fahrzeug muss allerdings eine Ressource sein: Optimiert die SPS ein Fahrzeug über einen eigenen Auftragspuffer – etwa einen Verteilwagen –, genügt es, die bedienten Meldepunkte zu definieren.
4. Architekturentscheidungen: Was im Blueprint geklärt werden muss
Die wichtigste Weichenstellung fällt im Business Blueprint, bei der Abstimmung der Telegrammschnittstelle mit dem Anlagenbauer. Dort zeigt sich, was die Steuerung als Ziel erwartet und wie viel Wegfindung sie selbst übernimmt. Daraus ergibt sich die passende Routing-Logik.
Die Falle liegt beim Begriff selbst. Nur weil über eine Palettenanlage gesprochen wird, muss es keine Lagerungssteuerung werden. Wer die Entscheidung am Wort „Behälterfördertechnik“ festmacht statt an der Schnittstelle, landet schnell bei der falschen Variante und merkt es erst, wenn das Customizing steht.
4.1 Performance ist bei der BFT ein Architekturthema
In der Behälterfördertechnik ist die Antwortzeit auf eine Routinganfrage die zentrale Randbedingung. Der Behälter steht an der Kreuzung und wartet auf eine Richtung; jede Verzögerung schlägt unmittelbar auf den Durchsatz durch.
Daraus ergeben sich ein paar harte Regeln für Erweiterungen:
- Im Routing-Pfad gehört performantes Coding hin. Keine hochkomplexen Algorithmen, keine ausufernden Ermittlungen.
- Keine Buchungen im Routing selbst. Alles, was schreibt, verlängert die Antwortzeit.
- Aufwendige Ermittlungen und Buchungen wenn möglich asynchron ausführen, so wie es die Grobplatzermittlung aus Kapitel 3 vormacht.
Als Faustregel für eigene Erweiterungen: Was im Routing-BAdI nicht in wenigen Millisekunden abgearbeitet ist, gehört dort nicht hin.
4.2 Queue oder direkter Versand – ein grundlegender Unterschied
Ein architektonischer Unterschied, der im Customizing kaum sichtbar wird, betrifft den Weg des Telegramms zur SPS. Bei der Lagerungssteuerung landet jede Lageraufgabe, die an die Steuerung gehen soll, zunächst in einer SPS-relevanten Queue. Diese Queue wird ausgelesen, und erst dann geht die Lageraufgabe raus.
Dieser Zwischenschritt hat einen praktischen Nutzen. Vor dem Senden lässt sich prüfen, ob der nächste Meldepunkt oder das nächste Fördersegment überhaupt noch Kapazität hat, um die HU aufzunehmen. Ist das nicht der Fall, bleibt die Lageraufgabe einfach in der Queue liegen. Die Palette wird gar nicht erst losgeschickt. Dasselbe passiert, wenn die SPS eine Störung an einem Fördermittel meldet.
Kapazitätsgrenzen lassen sich dabei auf Meldepunkte, Fördersegmente oder Ressourcen legen. Fördersegmente muss man übrigens nur dann definieren, wenn man ihren Status und ihre Kapazität in EWM führen will. Oft genügt es, beides an den Meldepunkten zu pflegen.
Die Behälterfördertechnik hat diese Zwischenstufe nicht. Im Standard wird nur die Richtung ermittelt, das Antworttelegramm direkt im Coding erzeugt und sofort gesendet. Kein Puffer, keine vorgelagerte Kapazitätsprüfung, keine Möglichkeit, eine Anfrage zurückzuhalten.
Was das praktisch bedeutet
Mit der Lagerungssteuerung lässt sich Stau vermeiden, bevor er entsteht, weil die Kapazitätsprüfung greift, bevor die HU in Bewegung kommt.
Bei der BFT fährt die HU los und wird notfalls über den Default umgeleitet. Der Stau lässt sich damit nicht verhindern, die HU fährt aber daran vorbei.
4.3 Telegrammverarbeitung richtig dimensionieren
Zurück zur Performance, diesmal aus Sicht der Infrastruktur. An einer laufenden Anlage fragen mehrere Meldepunkte gleichzeitig an, und zwar dauerhaft und nicht nur in Spitzen.
- Mehrere parallele Prozesse für die Telegrammverarbeitung erlauben. Ein einzelner Prozess wird zum Nadelöhr, sobald mehrere Meldepunkte gleichzeitig anfragen.
- Die Telegrammverarbeitung auf einen separaten Applikationsserver auslegen, damit dauerhaft genügend Prozesse zur Verfügung stehen und der Dialogbetrieb nicht dazwischenfunkt.
- Statustelegramme vom Routing entkoppeln: mehrere Kanäle pro SPS, zum Beispiel einer für Routinganfragen und einer für Statusmeldungen.
Die Kanaltrennung wird dabei oft übersehen. Je nach Anlagengröße laufen sehr viele Routinganfragen auf, und jede einzelne blockiert einen Behälter. Statusmeldungen sind dagegen deutlich seltener und zeitlich unkritisch, sie müssen gar nicht innerhalb der Telegrammsequenz abgearbeitet werden. Läuft trotzdem alles über denselben Kanal, kann eine einzelne Statusmeldung die dahinter wartenden Routinganfragen ausbremsen.
Wie sich die Telegrammkommunikation im Betrieb überwachen und Störungen eingrenzen lassen, beschreibt unser Beitrag „Telegrammmonitoring in SAP EWM MFS: Retry, CP Channels, Queue-Staus und Debugging in der Praxis“.
4.4 Weitere Stolperstellen
Ein weiterer Punkt ist die Platzierung der Meldepunkte. Zum einen im Customizing: Aktionen, die Lageraufgaben anlegen, ändern oder quittieren, sollten nicht an dicht beieinanderliegenden Meldepunkten ausgelöst werden – sonst drohen Sperrkonflikte in der LB-Verarbeitung.
Zum anderen ganz physisch auf der Anlage: Liegen zwei Meldepunkte zu eng beieinander, bleibt zu wenig Zeit zwischen den beiden Anfragen. Im Customizing sieht das sauber aus, zum Problem wird es erst zur Laufzeit.
5. Praxisvergleich: Derselbe Prozess mit zwei Routing-Logiken
5.1 Rücklagerung mit LOLS
Nehmen wir das Palettenlayout aus Kapitel 2. Am Kommissionierplatz 1 ist die Entnahme fertig, die angebrochene Palette soll zurück ins Regal, konkret in Gasse 3 auf den Lagerplatz 0083-05-04-03. Direkt geht das nicht, zwischen KP1-OUT und der Gasse liegen zwei Meldepunkte und der Einlagerpunkt.
So arbeitet sich die layoutorientierte Lagerungssteuerung durch:
| Etappe | Quittierung auf | LOLS findet | Daraus entsteht |
|---|---|---|---|
| Start | — | Zwischenlagerplatz CP1 | Inaktive LB KP1-OUT → 0083-05-04-03 plus offene LB KP1-OUT → CP1 |
| 1 | CP1 | Zwischenlagerplatz CP2 | Neue offene LB CP1 → CP2 |
| 2 | CP2 | Zwischenlagerplatz EP3 | Neue offene LB CP2 → EP3 |
| 3 | EP3 | kein Zwischenlagerplatz mehr | Die inaktive LB wird aktiviert: EP3 → 0083-05-04-03 |
Eine durchgehende Wegbeschreibung existiert dabei zu keinem Zeitpunkt. Das Ziel steckt zwar von Anfang an in der inaktiven Lageraufgabe, der Weg dorthin entsteht aber erst nach und nach, jeweils beim Quittieren der vorherigen Etappe. Liefert die Prüfung keinen weiteren Zwischenlagerplatz mehr, wird die inaktive Lageraufgabe aktiviert und übernimmt den Rest.
Die letzte Etappe von EP3 auf den Lagerplatz fährt das Regalbediengerät. Damit greift die Regel aus Kapitel 3, dass Ressourcen unabhängig von der Routing-Logik auf der Strecke immer eine Lageraufgabe brauchen.
Warum die Lagerungsgruppe hier den Unterschied macht
An CP2 muss sich entscheiden, ob es zu EP1, EP2, EP3 oder EP4 geht. Über den reinen Nach-Lagertyp 0083 ist diese Frage nicht zu beantworten – der ist für alle vier Gassen derselbe.
Dafür ist die Lagerungsgruppe (/SCWM/TROUTLS) da. Sie unterteilt den Lagertyp so weit, dass die layoutorientierte Lagerungssteuerung die richtige Gasse ansteuern kann.
Fehlt einer der vier Sätze im Customizing, etwa der von CP2 in Richtung Gasse 3, findet die Prüfung nichts. Einen Vorschlagswert, der einspringt, gibt es nicht. Stattdessen wird die inaktive Lageraufgabe aktiviert, und die SPS bekommt ein Telegramm mit einem Ziel, das sie von dieser Position aus nicht anfahren kann.
5.2 Wenn der Einlagerpunkt belegt ist
Interessanter wird es, wenn etwas dazwischenkommt. Die HU ist unterwegs auf der offenen Lageraufgabe CP2 → EP3, doch EP3 ist gerade belegt. Absetzen lässt sie sich dort nicht, also fährt sie vorbei und dreht ihre Runde im Loop weiter.
Was dabei im EWM passiert:
- Die HU meldet sich am nächsten bekannten Meldepunkt zurück – hier CP1.
- Die offene Lageraufgabe CP2 → EP3 wird mit dem Ausnahmecode CHBD quittiert. CHBD steht für Change Destination Bin und erlaubt es, den Nachlagerplatz bei der Quittierung zu ändern – gebucht wird also auf CP1 statt auf EP3.
- Das Ziel 0083-05-04-03 in der inaktiven Lageraufgabe bleibt erhalten, ihr Vonlagerplatz wandert auf CP1 mit.
- Mit der Quittierung wird die layoutorientierte Lagerungssteuerung erneut ausgewertet – diesmal ab CP1. Und dort gibt es einen Eintrag Richtung Gasse 3 über CP2.
- Es entsteht eine neue offene Lageraufgabe CP1 → CP2, und die Etappenkette läuft ein zweites Mal.
Die HU dreht also eine Runde und probiert es erneut, solange EP3 belegt bleibt. Elegant ist das nicht, funktioniert aber, weil der Loop die HU zwangsläufig wieder an einer Position vorbeiführt, die in der layoutorientierten Lagerungssteuerung als Von-Position gepflegt ist.
Der Preis dieser Rettungsschleife
Jede Position, an der eine HU ungeplant landen kann, muss in der LOLS als Von-Position gepflegt sein – sonst endet die Kette dort.
Bei einem sauberen Loop ist das überschaubar, weil ohnehin nur wenige Meldepunkte in Frage kommen.
Bei verzweigten Layouts wächst der Pflegeaufwand schnell, und die Lücken fallen im Testbetrieb selten auf.
In der Behälterfördertechnik gäbe es diesen Fall so gar nicht, weil dort an jedem Meldepunkt ohnehin neu entschieden wird, ohne vorherige Quittierung. Ein belegter Einlagerpunkt wäre dort nur eine Richtungsentscheidung, die diesmal anders ausfällt.
5.3 Derselbe Weg mit BFT-Routing
Dieselbe Aufgabe im AKL-Layout: Eine HU kommt herein und soll in Gasse 3. Eine Etappenkette gibt es hier nicht, und unterwegs auch keine einzige Lageraufgabe.
Am Einschleuspunkt BFT1-IN wird die HU gescannt und die Kontur kontrolliert, gleichzeitig startet die Grobplatzermittlung. Auf das Ergebnis wartet die HU allerdings nicht, sie fährt schon einmal los, Richtung 1.
| Meldepunkt | Geprüft wird | Richtung | Konsequenz |
|---|---|---|---|
| BFT1-IN | Scan und Konturkontrolle, Grobplatzermittlung wird angestoßen | 1 | HU fährt weiter, die Ermittlung läuft im Hintergrund |
| SC6 | Liegt inzwischen eine Grobplatzermittlung vor? | 1 / Default 2 | Ja: weiter in den Loop. Nein: Ausschleusung über BFT1-OUT |
| SC1 | Zielaktivitätsbereich = Gasse 1? | 2 / Default 1 | Nein: geradeaus weiter |
| SC2 | Zielaktivitätsbereich = Gasse 2? | 2 / Default 1 | Nein: geradeaus weiter |
| SC3 | Zielaktivitätsbereich = Gasse 3? | 2 | Für diesen Meldepunkt und diesen Aktivitätsbereich ist Richtung 2 gepflegt – die HU biegt ab |
| EP3 | Scan der HU | — | Erst hier wird der finale Lagerplatz ermittelt und eine Lageraufgabe für das RBG angelegt |
Bis EP3 wurde ausschließlich gelesen: kein Quittieren, kein Ausnahmecode, keine inaktive Lageraufgabe im Hintergrund. Die Lageraufgabe entsteht erst dort, wo sie zwingend gebraucht wird, nämlich für das Regalbediengerät.
Gut zu erkennen ist auch die Rolle des Defaults. An SC6 fängt er den Fall ab, dass die Grobplatzermittlung noch nicht fertig oder gar nicht möglich war; die HU wird dann wieder ausgeschleust. An SC1 und SC2 heißt Default nur so viel wie „nicht meine Gasse, weiterfahren“.
5.4 Volle Einlagerbahn bei BFT
Ist die Bahn zu EP3 belegt, fährt die SPS je nach Programmierung trotzdem geradeaus weiter. Die HU dreht dann per Defaultrouting ihre Runde im Loop und probiert es beim nächsten Durchlauf an SC3 erneut, so lange, bis die Einlagerbahn frei ist.
Kein Fehler, kein Eingriff, keine hängende Lageraufgabe. Die HU bleibt in Bewegung, und irgendwann klappt es.
Die Kehrseite: irgendwann muss Schluss sein
Von sich aus hört die HU nicht auf zu kreisen. Ein Loopzähler, der nach n Runden ausschleust oder eine Meldung auslöst, ist im Standard nicht vorgesehen und muss selbst entwickelt werden.
Ohne diese Eigenentwicklung fährt eine HU im Zweifel unbegrenzt weiter – unauffällig im Betrieb, aber unschön für Durchsatz und Analyse.
Im Vergleich zu Kapitel 5.2: Bei LOLS musste die abweichende Position gebucht und die Kette neu aufgesetzt werden. Bei der BFT passiert im EWM dagegen nichts Besonderes. Die HU kommt wieder vorbei, wird gelesen, und die Entscheidung fällt erneut.
6. Grenzen: Was beide Ansätze nicht leisten
Beide Verfahren stoßen an dieselbe Grenze, wenn auch aus unterschiedlichen Gründen: Es sind Entscheidungsmechaniken und keine Wegefindung. Wer echte Routenoptimierung oder eine Ausweichlogik bei Störungen braucht, muss in beiden Fällen selbst entwickeln, nur an unterschiedlichen Stellen.
6.1 Was LOLS nicht kann
- Keine Bewertung ganzer Pfade. Es wird immer nur der nächste Schritt betrachtet.
- Ausweichoptionen über die Sequenznummer wirken ausschließlich lokal, nie über mehrere Etappen hinweg.
- Kein Default. Was nicht gepflegt ist, existiert nicht.
Vor allem der letzte Punkt hat Folgen. Fehlt ein Weg im Customizing, wird in der Regel die inaktive Lageraufgabe aktiviert und ein Telegramm mit einem nicht erreichbaren Ziel an die SPS gesendet. Betrieblich ist das unangenehmer als ein sauberer Abbruch, weil der Fehler erst in der Anlage sichtbar wird und nicht im EWM.
Abweichende Buchungen sind über den Ausnahmecode CHBD möglich – dann muss allerdings jeder Weg, der falsch laufen könnte, ebenfalls in der layoutorientierten Lagerungssteuerung erfasst sein. Das skaliert schlecht und fällt im Testbetrieb selten auf.
6.2 Was die BFT nicht kann
- Alternative Routen bei blockierten oder gesperrten Meldepunkten sind im Standard nicht vorgesehen.
- Das Customizing ist relativ starr; eine komplexe Wegefindung müsste entwickelt werden.
- EWM kennt die Topologie hinter einer Richtung nicht und kann deshalb gar nicht ausweichen.
6.3 Eine Schwäche, die zur Stärke wird
Was der BFT die Alternativroute verwehrt, macht sie im Betrieb robust. Weil an jedem Meldepunkt ein Default-Satz existiert, bekommt die SPS immer eine Antwort. Ein Behälter bleibt nie stehen, im Zweifel fährt er Richtung Klärplatz und räumt sich damit selbst aus dem System. Fehlt bei LOLS der passende Satz, bleibt die Palette dagegen liegen.
7. Fazit: Die Schnittstelle entscheidet, nicht der Ladungsträger
Lagerungssteuerung und Behälterfördertechnik beschreiben weniger den Ladungsträger als die Frage, wie viel Entscheidung im EWM liegt und wie viel in der Anlage.
LOLS baut eine Kette aus Lageraufgaben über Zwischenlagerplätze auf. Das Ziel steht früh fest, die Nachvollziehbarkeit ist hoch und der Pflegeaufwand ebenfalls. Ohne passenden Customizing-Satz gibt es allerdings keinen Plan B. Die BFT-Logik entscheidet kleinschrittig, telegrammgetrieben und rein lesend an jeder Kreuzung. Gut für den Durchsatz, aber ohne Alternativroute.
Für die Projektpraxis heißt das: Die Entscheidung für eine der beiden Logiken fällt nicht im EWM-Blueprint, sie ergibt sich aus der Schnittstelle zur Steuerung. Wer das früh klärt, spart sich später ein Umbauprojekt.
Die Projektregel in einem Satz
Wer im Blueprint nicht klärt, ob die SPS ein Ziel oder nur eine Richtung erwartet, entscheidet nicht über ein Customizing-Detail, sondern über die gesamte MFS-Architektur.
Wann SAP EWM MFS insgesamt sinnvoll ist und wann ein externer Materialflussrechner besser passt, zeigt unser Beitrag „SAP EWM MFS vs. WCS: Wann SAP EWM MFS sinnvoll ist – Architektur, Grenzen & Praxiserfahrungen“.
Häufig gestellte Fragen zu LOLS und BFT-Routing
Antworten auf typische Fragen aus Blueprint, Customizing und Betrieb zur Wahl zwischen layoutorientierter Lagerungssteuerung und Routing für Behälterfördertechnik in SAP EWM MFS.
Ja. Ausschlaggebend ist, was die SPS im Telegramm erwartet und wie viel Wegfindung sie selbst übernimmt. Bei einer Steuerung, die von Kreuzung zu Kreuzung eine Richtung braucht, passt das BFT-Routing auch für Paletten.
Weil die layoutorientierte Lagerungssteuerung keinen Default kennt. Fehlt der passende Satz, gibt es keinen Ausweichweg. Die Behälterlogik hat immer einen Vorschlagswert und schickt die HU notfalls zum Klärplatz.
Auf der Strecke nicht zwingend – die Routing-Entscheidung ist rein lesend. An Ressourcen wie Regalbediengeräten dagegen schon: Dort braucht es unabhängig von der gewählten Logik immer eine Lageraufgabe.
Weil nur die Lagerungssteuerung vorab prüfen kann, ob der nächste Meldepunkt oder das nächste Fördersegment überhaupt Kapazität hat. Die Queue ist das Werkzeug dafür: Reicht die Kapazität nicht, bleibt die Lageraufgabe einfach liegen. Die BFT hat diese Zwischenstufe nicht, sie sendet direkt.
Die HU muss nicht auf das endgültige Ziel warten, um loszufahren. Das hält die Anlage schnell, weil die aufwendige Ermittlung im Hintergrund läuft, während die HU schon unterwegs ist.
Aus zwei Gründen. Im Customizing drohen Sperrkonflikte, wenn mehrere LB-Aktionen zu eng getaktet ausgelöst werden. Physisch auf der Anlage bleibt schlicht zu wenig Zeit zwischen zwei Anfragen, damit die Antwort noch rechtzeitig ankommt.
