Discover SAP EWM MFS 

The communication from EWM to the PLC

This blog is part of the series ‘SAP EWM meets Automation – Discover EWM MFS’ and describes the communication between EWM and the PLC. Specifically, the communication from EWM to the PLC.
As a practical example I picked the creation and communication of a stock removal warehouse task from an automated storage & retrieval system to describe this communication:

.
However, the general approach is also applicable for other kinds of telegrams which are being sent from EWM to a subsystem via TCP/IP.
Note that with this post we will limit the scope to an APC (ABAP Push-Channel) communication based on the TCP/IP protocol suite. Up to EWM release 9.3 a TCP/IP-RFC converter is required which will not be in scope of this post.

Also note that the communication steps for the direction from the PLC to EWM will not be part of this post. For everybody who wants to understand how EWM receives telegrams I highly recommend the blog post published by Joerg and Tobias here.

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!

Agenda

– Communication protocol
– Preparation of telegram creation
– Telegram creation & transmission
As an introduction, let us have a look at the VDI 3962 layer model for computer installations in automated storage systems:

The red arrow highlights the part of the communication which is in scope of this post:

Quick recap at this point –
In the previous blog post we already learned that the queue determination induces the MFS relevance for a given warehouse task:

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

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) based on the constant in line 261 in the screenshot below:

…recap completed.

At this point, EWM has decided that a given task has to be processed by the subsystem. We assume this to be our initial situation here. So we start with a queue which is
– customized as being MFS relevant
– carrying multiple WTs in status ‘Y’ (relevant for subsystem but not sent to subsystem yet).

So how do we get from here to actually have the subsystem receiving one of those tasks?

The important components are shown in the overview above and described in this post in detail. We will now have a step-by-step look at the important technical details of the communication (bear with me if I skipped some that you consider to be important!).
Before we start with this deep-dive I would like you to understand the protocol which is responsible to ensure a reliable communication. While EWM is communicating with a subsystem we want to make sure that telegrams of a given channel are processed sequentially. This is realized by the handshake mechanism which is the main pillar of the PLC communication protocol:
– The sender sends a telegram and stores is in its outbound buffer in status ‘sent’ but ‘not acknowledged yet’.
– The sender repeats a message sending a telegram as long as it is not acknowledged in a defined period of time (X times every Y seconds)
– The next telegram of the given channel is only sent once the previously sent telegram is acknowledged.
– The receiver sends an acknowledge message for every message it receives
– The receiver processes a message only once (~ only the first time it receives it)

Analogy –
Imagine you are trying to communicate with your kids. Those of you having young kids will know that they like to ignore you in case you tell them something they do not like to hear.

So imagine the handshake mechanism here as an approach where you only proceed with the next sentence once your kid has confirmed that he/she actually heard the previous sentence. As long as he/she ignores you, you will just proceed saying the same thing all over again. Not sure though how we can incorporate the restart of the channel after X attempts in this analogy. However, you might want to think about opening an additional channel and e.g. start communicating via Whatsapp only .

Step 1: Which WT to be processed?

As mentioned above, MFS-relevant tasks are assigned to queues. Subsequently, in the first step we need to decide which of the WTs from the given queue is selected as the next one to be processed (~ sent to subsystem). This is done via FM /SCWM/MFS_WT_DET. This FM is called directly in the context of posting the WT creation and WT confirmation to the DB:

The check during the confirmation is required e.g. in case the telegram for a newly created WT cannot be created right away during the initial posting of the new task (e.g. in case the crane for the given source aisle is busy at that point in time).

The most important steps that EWM executes in FM /SCWM/MFS_WT_DET:

– execute some checks here (e.g. availability/status of PLC/resources/channel)
– decide whether to do interleaving
– apply standard sorting.

Within the queues, EWM sorts ascending based on latest start date, priority and warehouse order number (the logic can be overruled via Badi /SCWM/EX_MFS_WO_DET2 and/or /SCWM/EX_MFS_WT_DET):

Note that EWM applies some additional checks here depending on the context (e.g. use FM /SCWM/MFS_WT_DET_PREP to check if source location of WT is a communication point and if there are any other HUs on the same CP which have to be processed first). This is not relevant for the first movement in our example but might become relevant later for subsequent steps towards the final destination of the HU which is to be removed from stock here.

Finally we are at the point where the WT to be processed is determined and EWM calls the FM to send the telegram:

.
Step 2.1: Prepare the telegram creation

Once a WT is selected, EWM triggers the creation and transmission of the telegram via function module /SCWM/MFS_SEND. This FM is the most important one from the perspective of this article here and is creating the outgoing telegram from technical perspective.

Note that this FM is called from multiple other places (e.g. to trigger the creation of an acknowledgement telegram in the context of processing one which had been received from the subsystem). I limited the scope of the post to the context of the creation of a telegram for a warehouse task.

The FM starts composing telegram content based on the WT data (mainly derived from /SCWM/ORDIM_O table). Note that this happens in case the FM is called directly from the WT creation.

In other cases (e.g. acknowledgement for received telegram, waiting telegram from MFSDELAY table or resend from warehouse monitor), a telegram does already exist and is imported directly (this scenario is not in scope of this post):

Then we then we check whether a resource (e.g. a crane operating an ASRS) is involved and whether the resource requires a separate task to confirm the HU to/from the resource itself before it is confirmed to the actual destination of the task. The decision is derived from the resource type customizing:

The next important step is the mapping of EWM objects to PLC objects via FM /SCWM/MFS_TELE_MAP which calls /SCWM/MFS_EWM2PLC_OBJ in our context (communication direction EWM > PLC) where EWM reads the mapping data from table /SCWM/MFSOBJMAP (maintained via transaction /SCWM/MFS_OBJMAP):

If needed you can also call Badi /SCWM/EX_MFS_TELE_EWM2PLCOB in this context in order manipulate/provide the mapping between EWM & PLC objects:

After the communication channel has been locked successfully, EWM now determines some technical details like telegram type and the communication channel and its parameters/settings. Badi /SCWM/EX_MFS_TELE_CCH_DET could be used here in order to manipulate the determination of the communication channel:

Finally we call Badi /SCWM/EX_MFS_TELE_SND where we could potentially manipulate telegram data or type:

If the telegram to be sent does not require an acknowledgement from the subsystem (~ handshake mode) EWM updates KZSUB parameter in the WT already at this point to value ‘X’:

Our telegram is ready to be sent now. Based on the handshake configuration we do now either send it right away or at first check the send buffer (table /SCWM/MFSDELAY) for the given PLC and channel in order to figure out whether there are any other waiting or unconfirmed telegrams (~ telegrams which have been sent to the subsystem but for which EWM did not receive an acknowledgement yet). If telegrams are sitting in the delay table, EWM stores the data for the current telegram in table also in this table but does not send it yet
– Sidenote: Upon completion of the waiting telegrams, the receiving process which is processing the acknowledgements (executed via function module /SCWM/MFS_RECEIVE2) picks up our telegram from the buffer and actually sends it – again, using FM /SCWM/MFS_SEND:

.
Step 2.2: Create the telegram

Let us assume, no waiting telegrams can be found in the buffer table. EWM now sends the current telegram to the subsystem directly. For this purpose we pull a sequence number for the telegram (this is essential for the communication protocol to work) via FM /SCWM/MFS_SND_SEQNO_GET. Based on the sequence number EWM is able to identify a telegram uniquely for a specific period of time (in combination with the channel and the direction). The number is pulled from the channel data, stored in table /SCWM/MFSCCH:

.Note that the way of drawing a sequence number here can be manipulated via Badi /SCWM/EX_MFS_TELE_SEQU_NO.

As part of the next step, EWM fills the structure of the telegram type (so far we filled a generic structure only) with the local data via FM /SCWM/MFS_MOVETELETOTAL2STR and add filler characters if required.

In case the handshake mechanism is active for the given communication channel, the telegram data is stored in table /SCWM/MFSDELAY even though it is communicated to the subsystem within the next step. This approach allows to retry/resend the telegram in case of errors during the communication (e.g. retry via the MFSPERIOD job in case no acknowledgement has been received after X seconds). In the example from the screenshot below, EWM would resend the telegram every 10 seconds. After the 3rd approach it would close and re-open the channel ahead of the next attempt.

The record for this telegram will be removed from the buffer table automatically in the context of processing the acknowledgement for the given telegram sequence number from the subsystem.

The last step before we finally send the telegram is the activation of the log respectively to log the telegram data based on the given settings.

Step 2.3: Send the telegram

Now we finally handover the telegram to the PLC based on the given communication method. This is done via FM /SCWM/MFS_CL_CALL. As part of this FM we first determine the communication details of the PLC (1) and the channel (2):

Based on the communication channel application data we determine technical details about the destination we are about to talk to (IP address / host & port):

Based on the PLC application data we know whether we communicate with a middleware/RFC-converter like PlantConnectivity, a proprietary communication layer (e.g. an emulation) or directly with the subsystem via ABAP Push Channel (APC):

As mentioned at the beginning of this article, the APC approach is in scope of this article. In this context, class /SCWM/CL_APC_EXT_MFS_TCP_PLC is called to execute the TCP/IP based communication with the subsystem:

.
I decided to stop at this point and will not dig deeper into the details. From here onwards it is all about complex technical stuff in order to enable and execute the TCP/IP based communication. Not necessary to understand from my point of view, unless you want to become a MFS core developer or need to change/analyse something in this area of the coding (which should rarely happen as part of your MFS projects).
You should understand though, that the subsystem will send an acknowledgement telegram back to EWM and stores the telegram in its receiving buffer, before it actually processes it.

Step 3: Check whether we already received something

At the very end of our Send-FM EWM tries to process the answer from the subsystem right away via FM /SCWM/MFS_RECEIVE2:

.
I stop here with a hint the blog post of Joerg and Tobias, where they will unveil the details of the logic to process incoming telegrams.

Side note –
I mentioned the Telegram Repetition Process via the Batch Job MFS_PERIODCHECK multiple times in this article. This job (respectively report: /SCWM/R_MFS_PERIODCHK_PREP / FM: /SCWM/MFS_PERIODCHK) is an essential component of the MFS logic and is mainly responsible to monitor the connections and trigger the repetition of telegrams. It is

• responsible for all channels within warehouse number
• started automatically when a channel is started (via the warehouse monitor)
• stopped automatically when all channels are stopped (after timeout)
• sending LIFE check telegrams on timeout
• checking for outstanding acknowledgement telegrams
• repeating telegrams n times with the same sequence number before it closes and reopens the channel

Summary

You should have a rough understanding about how EWM sends telegrams to subsystems like crane or conveyor PLCs. As an example we looked at the creation and communication of a telegram for a warehouse task which removes an HU from a ASRS. We saw how EWM decides whether a task is relevant for the subsystem and how it decides which task of a given queue is the next one to be processed. We learned how the telegram is created, buffered and finally pushed out of EWM to its destination.