Discover SAP EWM MFS – Simulation / Emulation

by

Discover SAP EWM MFS

Simulation / Emulation

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!

With this blog post I look into the EWM standard simulation/emulation which you can use within your MFS projects in case you do not have the possibility to test/work with the real hardware/subsystems (yet).

Before we look into the agenda, let us tackle the question “What is the difference between a simulation and an emulation and what do we have in standard EWM MFS?”.

Simulation vs. Emulation

I give you my interpretation right at the beginning –

I do think what we have in EWM standard can be described with the term ‘Emulation’. This is at least my understanding based on the definitions that I found while researching this topic/question. Here is a collection of descriptions & definitions that helped me coming to my conclusion.

It’s a difference in focus. Emulators focus on recreating the behavior of a system, with no regard for how the system functions internally. Simulators focus on modeling the components of a system. You use an emulator when you care mostly about what a system does, and a simulator when you care about how it does it.

Emulation comes from æmulus, “striving, rivaling,” and is related to “imitate” and “image,” which suggests a surface-lever resemblance. “Simulation” comes from similis “like”, as does the word “similar,” which perhaps suggests a deeper congruence.

By that I mean that you use an emulator when you can’t use the real thing, and you use a simulator when you can’t use the real thing and you want to find something out about it.

An emulator is an alternative to the real system but a simulator is used to optimize, understand and estimate the real system.

Source: https://stackoverflow.com/questions/1584617/simulator-or-emulator-what-is-the-difference

The flow of loads within the simulation are controlled by algorithms developed to closely mirror how the system would be controlled by a real WCS or WMS.

An emulation model is generated and is used to test and commission the WCS controls software. Interfaces within the emulation model allow the WCS to connect as it would connect to the real Automated Material Handling System.

Source: https://www.logistex.com/post/why-simulating-emulating-warehouse-automation-makes-sense

Conclusion –

As mentioned above, I do think that we have an emulation in EWM standard although the name & description of the function module that EWM offers (details later) indicates that it provides a simulation. Anyways – for me it is an emulation and hence, for the rest of this article I will stick to this term.

Having answered this initial question, let us look the agenda for the remaining part of the blog-post:

  • Simulation vs. Emulation
    • What are the differences and what do we have as part of standard EWM? > Already covered at this point. See above for the answer!
  • Purpose / Use-Cases
    • What can the emulation do and what can it not do for us?
  • SAP Standard MFS emulation
    • How do we use the emulation in the context of EWM MFS?
  • Configuration
    • Hands-on! What do we need to configure in order to use the emulation?
  • Code-Review
    • How is the standard emulation implemented technically?

Purpose / Use-cases

The emulation in EWM is needed during the development & testing phase, when

  • the real hardware is not installed yet (so there is no real connection with the PLC), or
  • the real hardware is installed but it is simply too much effort to use it for testing (~ as tests with the hardware are time-consuming (~costly) you usually start testing with real hardware only once you are sure that a given configuration/development is working fine with the emulation).

So what are the things that you can test with the standard emulation and what can it not be used for?

I start with a list of things where it can really be useful:

Routing / LOSC

  • As the emulation will automatically confirm intermediate tasks for you, you can easily test complex routings based on the LOSC (+ its enhancements) without having to confirm all intermediate tasks manually. That means you can validate your customizing of multiple routes even for complex networks without spending much time

Validation of format & content of outgoing telegrams

  • As a result of using the emulation you will get telegrams looking like they will look like when you are later communicating with the real subsystems. Thus, you can validate whether your code creates telegrams in a format and with a content which is in line with what you agreed upon with your subsystem/team vendor as part of the interface specification

Processing of incoming telegrams with different content

  • You can mass create the incoming telegrams with different data for multiple different scenarios. This way you can for instance easily emulate all kind of errors that might be sent from the subsystem to EWM and validate the EWM coding which is supposed to process those errors

Having discussed the areas where the emulation is useful, let us now focus on the areas where it is not useful or at least does not really help you to validate your setups.

Communication layer

  • As long as you are using the pure ABAP-based EWM emulation (details later in this blog post), you are not communicating with an external system at all. So no matter whether you are planning to use a RFC-based or TCP/IP based or whatever-based communication layer, you are not testing it at all. Thus, this physical connection and its protocols & handshake mechanisms need to be tested separately with additional tools or even better the real subsystem as soon as it is available

Processing on subsystem side

  • Be aware that although the PLC looks & feels like a piece of hardware it has thousands of configurations and lines of code, even when controlling low-complex material flows. Whatever is sent to or received from EWM is processed by the logic sitting in the memory of the CPU. This whole configuration/coding on the subsystem is obviously ignored as long as we stay within EWM. Thus, you should not overrate what an emulation can do for you within your MFS projects! There is still a lot to be tested with the real subsystems!!

Emulation in the context of material flow systems

Let us now become a bit more functional/technical and first analyze the approach of emulating a subsystem in the context of a material flow system (no matter whether it is EWM controlling the MFS or any other WMS or MFC). You already know the graphic below in case you followed my blog so far. This is looking at the real world. The PLC is processing signals and communicates with EWM