Task Interleaving in an ASRS

This blog is part of the series 'SAP EWM meets Automation – Discover EWM MFS'. As with all posts of this series, the content provided here 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!

What is task interleaving and why is it important for MFS environments?

Before we dive into the technical details for interleaving in automated areas we should first clarify what task interleaving is from a functional perspective.

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:

EWM creates tasks in two queues – one putaway queue and one removal queue. In the scenario shown above, the warehouse operator receives the following sequence: putaway – putaway – putaway – removal. Interleaving now tries to mix up this sequence in order to save travel time for the operator. The resulting sequence could look like: putaway – removal – putaway – removal – putaway.

This is achieved by flipping queues. At a certain point the system decides that it is time to jump from the putaway queue to the removal queue and vice versa.

How does interleaving work in a Material Flow System with ASRS?

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?

The answer is: EWM implements interleaving for MFS by determining the next warehouse order to be processed based on the characteristics of the warehouse order instead of using queue flipping! When you drill down into the customizing (shown in the figure below) you will see that there is a flag which allows you to activate interleaving on a resource type level. This makes sense as it is a decision on the type of resource and not on the individual resource.

If interleaving is active for a resource type, EWM will try to alternate between putaway and retrieval tasks. This helps to minimize travel time in an ASRS as the crane needs to move through the warehouse in order to reach the different destinations.

Technical Implementation – Looking into the SAP EWM Code

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:

In order to fully understand the interleaving approach for ASRS we need to look at the actual implementation. We start in function module /SCWM/MFS_WT_DT which is responsible to decide which WT out of a pool of possible WTs (~ our crane queue) is the next one to be processed.

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:

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):

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.

Summary

• 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