Discover SAP EWM MFS

The EWM-PLC integration

This blog is part of the series ‘SAP EWM meets Automation – Discover EWM MFS’ and gives you an introduction to the EWM PLC integration and the MFS component of EWM. In this context, we will look at the most important objects which are used to represent the physical material flow components in MFS. In addition to this I will explain on a high level how the MFS component integrates with the subsystem/PLC layer.

Note that we will not look into the details of the communication between EWM and a subsystem as such. This will be part of additional post which I will release during the next months.

Also note that we will be focusing on the approach for the PLC integration which EWM uses for slow-moving MFS environments which are controlled based on the layout-oriented storage control (LOSC). In this context we are working with warehouse task triggering and pushing for the communication with the PLC. Fast-moving environments like case conveyor operations can make use of EWMs Case Conveyor Routing logic which does not require warehouse tasks to be created in order to initiate a communication (telegram exchange) with the PLC. The latter is not in scope of this blog post but will be tackled in a separate one (once I find the time… :-)).

Agenda

What are the most important objects that EWM uses to integrate its MFS component and to integrate with the PLC?

Communication points
Queues
PLCs
Communication Channels
Resources

As an introduction, let us one more time have a look at the VDI 3962 layer model for computer installations in automated storage systems:

The Inventory Management level could be covered by an ERP system like SAP S/4HANA. EWM with its in-built MFS component covers the Warehouse Management and the MFC layer:

EWMs MFS components integrates with the PLC which in turn controls sensors and drives. Check this blog post in case you want to learn more about what a PLC is and what it does.

As part of this post we will tackle the integration of the MFS component within EWM on the one hand but also the connection between the MFS component and the PLC on the other hand.

Based on this focus, we can simplify our model to the following view:

.EWM and MFS having the same color here as we are talking about one system. Still MFS can be viewed as a component within EWM, having its own objects which need to interlock with the components of core EWM. The term ‘subsystem’ along with a box in a different color represents the PLC and the hardware which is controlled by the PLC. We start now with a simple example of a physical material flow which should help us find our way through the rather theoretical theory. On the next picture you can see a part of a pallet conveyor system. A pallet is sitting on the conveyor segment number 0333 on the right side of the picture. This pallet should now travel to segment number 0111 in order to be picked up by the crane which you can see moving on the left part of the picture:

In EWM, the conveyor segments are created as storage bins and thus from EWM perspective this movement is nothing else than a warehouse task (+ warehouse order) from bin A to bin B:

The first MFS object which becomes relevant here is the communication point. Communication points are objects which attach additional characteristics / attributes to storage bins (e.g. capacity; follow-up CPs; clearing CPs etc.):

Communication points are mapped to EWM storage bins (either manually via transaction /SCWM/MFS_CP or via Badis /SCWM/EX_MFS_TELE_EWM2PLCOB and /SCWM/EX_MFS_TELE_PLC2EWMOB):

WTs are communicated to PLCs if they are added to queues which are relevant for MFS (~ have the respective parameter for the operating environment and a PLC linked to it). That also means that the communication of warehouse tasks to the subsystems is invoked by the queue determination rules (customizing). Again note that we are talking about slow-moving MFS environments using the layout-oriented storage control for routing. Case Conveyor Routing as an alternative can invoke the communication with the PLC without creating warehouse tasks upfront. This concept is not in scope of this blog post though.

Technically, EWM marks warehouse tasks for MFS processing via the field KZSUB:

And as mentioned above, this is being set based on the queue configuration. FM /SCWM/QUEUE_DET_PREP reads the queue customizing from table /SCWM/T346:

Here you can see that it is empty in the ltap structure initially and then set to ‘Y’ (~ relevant but not sent to the subsystem yet):

So the customizing shown in the screenshots above tells us which PLC is the receiver of the telegram which is about to be created. So beside the queue itself, the PLC is next MFS object which is important for the interlock between EWM core, MFS and the subsystem:

Application data and customizing for the PLC mainly define how EWM MFS communicates with the given PLC (e.g. APC vs. Plant Connectivity or structure of the telegrams) but also provides options to configure how EWM handles tasks which are assigned to the given PLC/queue (e.g. warehouse process types or exception codes):

The communication between the EWM MFS component and the physical PLC is done via telegrams:

In order to determine the destination for the communication we make use of the next important object in the context of EWM-MFS-PLC integration. The communication channel holds the technical details (e.g. hostname & port in the context of ABAP Push-Channels) which are needed for the telegrams in order to reach their destination:

The resource is the last object which I would like to mention here as being relevant for the interlock. Resources become relevant in case we are not just dealing with a conveyor moving something from A to B but e.g. with a crane which is handling a pool of tasks. EWM is again using one of its core objects and adds MFS-specific configuration options (e.g. clearing bins which are assigned to a crane or whether a crane should execute interleaving or not):

…that’s basically it. At least from my perspective, the important objects for the EWM-MFS integration. To close this quick walkthrough I would like to come back to our example where the PLC now received the warehouse task in form of a telegram and triggers the conveyor drives in order to move the physical pallet from source to destination:

Summary

I hope you do feel a bit more comfortable now with the most important objects that EWM uses to integrate with its MFS component as well as with the subsystems (~ the actual hardware). Be aware that I skipped some details in order to avoid distraction and to highlight the important points. I might come back to the specialties and technical details as part of additional posts.

Before that happens, I will give you a step-by-step overview of the communication from EWM to the PLC and the other way around. I am working on this and will release the articles during the next months.

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!

Discover SAP EWM MFS

The EWM-PLC integration

Get my monthly blog-updates!

Subscribe to my Youtube channel!