Discover SAP EWM MFS
Task interleaving in an automated storage & retrieval system (ASRS)
This blog is part of the series ‘SAP EWM meets Automation – Discover EWM MFS’ and describes the concept for task interleaving in automated areas respectively in the context of SAP EWM MFS.
We will take a quick look at the approach taken in manually operated areas again, before we head over to the automated ones. As usual, I mixed technical details with practical examples in order to make it easier for you to digest the content.
Note that this blog post has been created in cooperation with the SAP EWM team at Swisslog. Feel free to visit their website in case you want to learn more about the services offered by @ Swisslog or to browse open positions within their EWM team!
Agenda
- What is task interleaving at all?
- Recap interleaving approach for manually operated areas in SAP EWM
- Comparison of approaches for interleaving between manually operated and automated areas
- Customizing & Technical details for interleaving in automated areas
Task interleaving describes a process or strategy by which tasks of different types are combined with each other in order to reduce the total travel time and / or distance. For those of you who are not familiar at all with this concept I would suggest reading this blog article (or watching the corresponding video) in order to get a basic understanding.
As an introduction into this article I will only give a very quick recap about how EWM implements interleaving in manually operated (e.g. via radio frequency based devices / dialogues) areas of the warehouse.
We take this simple process as an example where we have forklift-operated movements of full pallets into and out of a pallet rack:
Instead of one team of operators executing the putaway and another team executing the pick tasks we want EWM to assign tasks in a way that every operator who completes a putaway tasks will get a removal tasks right away instead of driving back to the receiving area without any load in order to pick up the next putaway pallet. The same should be true for the picking process vice-versa. After dropping a picked pallet on the staging area the next task to be processed should be a putaway task. This way we are aiming to minimize the distance which is travelled without any load at all.
For this purpose we define two queues in EWM:
For those queues we do not only have to define a sequence for the given resource group (which we would need for ‘simple’ system-guided RF processing with multiple queues) but also a sequence for the different types of queues:
This queue type sequence makes sure that the resources which are operating within the respective resource groups will always get the subsequent task from a queue with queue type B once they’ve completed a task in a queue of type A.
I do not want to dig deeper into the details of the logic for manually operated areas here as the focus should be on task interleaving in automated storage and retrieval systems.
Thus, let us proceed with a different example from here onwards. Imagine an automated pallet high-bay storage, operated by multiple different cranes. For the sake of simplicity, imagine this high-bay storage having one aisle only, operated by one crane:
Cranes in automated storage & retrieval systems are created as resources in EWM. Check this blog (or this video) in case you want to learn more about important MFS objects like ‘resources’.
Other than RF resources, those MFS resources are assigned to exactly one queue and process warehouse orders from this queue in a specific sequence. So you might already notice that the approach with the queue sequencing (jumping in between putaway and removal queue types like described above) will not work here. So how does it work in such an environment?
In order to understand this we need to look into the code as the only customizing that EWM MFS offers for control here is this. Check this tiny little flag here along with a very lean documentation:
At least we get a definition of Interleaving in an EWM MFS context:
“By activating interleaving, you can avoid a situation where the resource travels empty from the aisle to the inclusion point, after putaway. Instead, the resource is given a new stock removal warehouse tasks before it returns. Interleaving therefore reduces the number of empty trips for the resource, and increases the throughput.”
So we know now where to activate task interleaving for the ASRS crane (respectively its resource type) in our example but how does it technically work? We only have one queue with tasks which is assigned to our resource:
In order to fully understand the interleaving approach for ASRS there is no other option than looking into the coding.
We start in function module /SCWM/MFS_WT_DT. For those of you who are following my blog this should sound familiar. This FM is responsible to decide which WT out of a pool of possible WTs (~ our crane queue) is the next one to be processed (check this blog post or video in order to learn more about the process of selecting WTs for telegram creation).
First EWM checks whether to execute interleaving at all. Subroutine check_resource sets variable lv_intleav with the help of FM /SCWM/RSRC_TRSRC_TYP_READ, based on the resource type customizing that I showed above:
We now have the answer to the questions whether interleaving is active or not (lv_intleav). For our example we assume it is active. Thus, EWM now calls subroutine check_interleaving in order to decide whether the next WT to be processed has to be
- a movement which is supposed to putaway a HU,
- or a movement which is supposed to retrieve a HU.
Remember, the main purpose of task interleaving is to realize a continuous cycle of putaway-retrieval-putaway-retrieval …. and so on.
Thus, in order to decide about the direction of the next movement, we need to determine the direction of the last movement (as we know the next one should point towards the opposite direction). EWM uses a simple but effective trick here. Based on the fact that the coding is called during task confirmation, EWM knows that our resource is currently located at the destination bin of the last movement. This destination bin is
- either a storage bin within our MFS storage type (in case the last movement has been a putaway task)
- or a handover storage bin (which has to be a communication point in order to induce the next movement) outside of our MFS storage type (in case the last movement has been a retrieval task)
So EWM simply checks whether the current bin of the resource is a communication point or not. If yes, the last movement has been a retrieval task and if not, the last movement has been a putaway task. It’s as simple as that:
You can see in the screenshot above that our famous variable cv_intleav is filled with different values based on the result of the check described above.
This variable is then handed over to subroutine select_wo which finally makes the decision which concrete warehouse order is the next one to be processed (~ the next one for which EWM will create a telegram and send it to the subsystem):
- The internal table lt_wo_rsrc_ty holds all started or open tasks for the given resource. EWM sorts the records based on the latest start date
- Based on the value of the local variable iv_intleav, EWM picks first the entry from the table in (1) which is supposed to be a picking/putaway task
- If a WO has been found, it is attached to the internal table et_who which holds all warehouse orders which could be processed next, along with the optimal sequence (sorted by putaway vs. retrieval and within those 2 groups also sorted based on the latest start date). Note: You can see in the screenshot that multiple WOs are written into this table – this is just to be sure that there is a backup in case the first one(s) cannot be processed for any reason.
You can see that SAP makes use of the content field from table /SCWM/WO_RSRC_TY (with this blog post we will not go into detail here about how this field is being filled – just keep it as a given that this table holds information which classifies a warehouse order as being a putaway or a retrieval task).
From the perspective of interleaving there is nothing more important within the subroutine select_wo. At the end it hands over the local table lt_who carrying the selection of sorted warehouse orders back to FM /SCWM/MFS_WT_DET. The upcoming coding grabs the first WT from the table and tries to create a telegram for this WT. Telegram creation is triggered at the very end of this FM via FM /SCWM/MFS_SEND:
From here onwards the logic has nothing specific in the context of interleaving and should not be in scope of this blog post. I wrote a different one in this blog-series from which you can derive all details about how EWM creates and sends telegrams to a subsystem.
Just a quick summary to close this one –
- Interleaving for MFS storage types is activated via the resource type customizing
- In contrast to interleaving in manually operated storage types, we are not using different queue types and queue sequences assigned to resources
- Every resource in a MFS environment is working with one queue only and thus, has to determine the next WO to be processed based on the WO characteristics instead of a queue flip-flop
- EWM uses the current bin of the given resource in order to figure out whether the last processed WT has been a putaway or retrieval task
Based on this insight it selects the next WT for the opposite direction. For this selection it uses the content field from table /SCWM/WO_RSRC_TY
I hope this blog post provides value to you and you could learn something. Please feel free to subscribe to my blog updates or my youtube channel in case you want to be notified about new posts!
Get my monthly blog-updates!
Subscribe to my Youtube channel!
