RFID: Overview and embedding in SAP EWM
All information in this blog is based on my own experience/ research. It’s written to encourage EWM consultants to explore this field and is (obviously) not a reference approach for implementation. 🙃
- What is RFID and for what is it used?
- The EPC Gen2 standard
- RFID in SAP Extended Warehouse Management
- Technical Details of SAP EWM RFID
What is RFID and for what is it used?
Radio Frequency Identification is a technology to identify and track tags attached to objects through electromagnetic waves .
That said, while RFID is a technology, it is not a standard by itself. It’s used in logistics, personal identification documents, toll collection, sports, animal and human tracking, electronic payment and many more fields. I recently read it’s even used for car thefts!
As for the tags being used there are passive tags: They reply to active readers after they are powered through the electromagnetic energy from the reader. You likely have seen such tags attached to articles in stores before.
Likewise there are active tags which are powered by a battery. They can emit information to active or passive readers.
For these purposes and hardware different standards are applied. That is necessary since they operate with different data speeds, in different frequency bands and provide ranges of identification from 0.1 to 200m.  For this blog we will now look at only one standard that has the widest adoption in supply chain worldwide and which is supported by SAP EWM.
The EPC Gen2 standard
The Electronic Product Code Generation 2 standard is defined by GS1 and GS1 US under the EPCGlobal Initiative. Likely you have heard of the GS1 when it came to barcoding standards for business like GS1-128 (former EAN-128), GS1-GTIN (e.g as in GTIN-13 former EAN/JAN/UCC-13) or GS1-DataMatrix. GS1 is a not-for-profit organization and the standards published are accessible for free on their web-presence.
EPC Tag URI and Pure Identity URI
While data on the tag is encoded in a binary format (see explanation in next paragraph of this blog), it is written in URI notation outside of the tags and inside SAP EWM. There are 2 ways to write the EPC, let’s first look at the Pure Identity URI with the example of an SSCC code (00)112345678000001749 where its ILN is 12345678, the extension digit 1 and the extension 174 and a calculated check digit of 9:
- Pure Identity URI: Used for EPCIS purposes and also stored in SAP EWM. It would encode the SSCC in the following way: urn:epc:id:sscc:12345678.100000174
Explanation: urn specifies the namespace to be an EPC code, id specifies it to be SSCC with 8 digit ILN separated by a dot, then the extension digit 1 followed by the extension without check digit.
- EPC Tag URI: Used in RFID communication (but not stored in the tag). It contains additional information. Above SSCC would be encoded: urn:epc:tag:sscc-96:2.12345678.100000174.
It specifies the EPC binary encoding scheme (96 bits SSCC) as well as a filter value of 2. Filter values are useful to quickly keep e.g. pallets from product tags apart or different types of HU types. A maximum of 7 filter values are allowed due to the 3 bit encoding.
In the next section we will learn how the EPC Tag URI is encoding into the tag’s memory banks.
EPC Binary Encoding on RFID Tag
Above shows how the memory is organized. The green and blue banks can be used in context of SAP EWM, the other banks are important for the reader infrastructure which is not part of this blog.
Starting from address 20h until 210h EPC data can be stored. The EPC data length is variable as we will see depending on the type of EPC and stored binary. Therefore any logic that generates the EPC data must fill always up to the word (encoding on bit but storage on byte).
Below is the layout how e.g. an SSCC code (as SSCC-96) is stored in the EPC memory bank of an RFID tag.
Now that we got a better idea of the data stored on EPC Gen2 tags let’s move over to SAP EWM.
RFID in SAP Extended Warehouse Management
RFID support for EPC is not new, it was already there in SAP EWM 5.1. For using it SAP EWM should be combined with SAP AII (Auto ID Infrastructure). This is a separate piece of software running on Netweaver stack and connects to SAP EWM through RFC/ web services. An overview of functionalities can be found in the SAP Help.
Now, I had no SAP AII at hand when I wrote this blog and so might you. Therefore we’ll be going a little DIY exploring what we can find in SAP EWM alone. I used a S/4HANA 2020 FP02 system, very likely any other release will work in the same way for RFID.
Edit: There is a new kid on the block to integrate RFID (and much more) called SAP Smart Sensing (which is part of SAP IoT). Thank you rollo van der sar for that addition! Once I’m clear on the integration piece I plan to add this to below technical information.
Basic architecture of RFID with SAP EWM
Below is a very simple outline of the architecture. You can interface through web services or RFC module to and from SAP EWM.
Technical Details of SAP EWM RFID
There are a few objects to know when working with RFID in SAP EWM. Let’s look at them one by one.
The function group /SCWM/RFID has one function module /SCWM/RFID_ACTION. This is the heart for performing all RFID actions. It is RFC enabled and called by AII. Likewise I used it to call it directly in a test program as I had no AII at hand. You can perform the following actions with it:
- Unload: With this you can unload EPCs through RFID from an inbound delivery. It requires however (at least in standard) that you have already EPCs stored in your inbound delivery. I’ll come to that point later.
- Move: You can move e.g. an HU or more with that action in EWM. You need an open WT for that according HU in standard.
- Pack: Packing of GTINs into an HU EPC or packing of HUs into an HU. The hierarchy must be clear through the scan or else you need to define it in a BAdI /SCWM/EX_RFID_PACK_ACTION.
- Load: The name says it. Load an EPC in the outbound loading process.
- Others: BAdI /SCWM/EX_RFID_OTHER_ACTION needs to be implemented. I think this is a place you would very likely want to touch. At least I needed it without AAI to create(!) EPCs in the EWM system.
The other FuGroups are auxiliary (e.g. DB update through update FM or UI/ generated views) so I leave them aside for that blog.
Classes and their methods are used by the above FM for all actions. Let’s look at them now.
- /SCWM/CL_RFID: Has all core methods to create, modify and delete EPCs in EWM. This manages the persistence layer.
- /SCWM/CL_RFID_ACTION: Actually these are called from the action FM. Have a look at them to get a good understanding of how the actions are structured.
- /SCWM/CL_RFID_SERVICES: Encodings and conversions as you have seen in my EPC standard explanations above. However: Not all of the needed conversions are in there (they are likely in AII), so I had to develop some for decimal to binary and binary to hex conversion to calculate the hex notation for the tag as this is a mandatory value in the EPC persistence layer. If you need help in understanding these let me know, I skip it for the sake of keeping the blog in a readable size.
Now where does the data go? There are two tables:
- /SCWM/EPC: This holds all EPC data be it products (GTINs), HUs or even resources with RFID assignment (see above). It looks something like this (based on my tests):
You see 3 HUs (Category A) and 1 Resource (Category E). Also one of the HUs got scanned (in an unloading process). Scanning meaning it passed a reader in the warehouse connected to SAP EWM. I called the “UNLOAD” action to achieve this. I also circled in the assigned underlying object (a circular reference for the RFID equipment and for the HUs are reference to the GUID of the HU.
- /SCWM/EPC_ASSN: This contains EPCs assigned to other EPCs – like a packed GTIN in an HU or a nested HU. I didn’t do this for my tests so I have no evidence to show. It would be created in a PACK action.
RFID can be easily extended – you find the according BAdIs in the IMG. I’ve mentioned some above. You can also apply all kinds of checks to EPCs to make sure a reader doesn’t trigger an action (e.g. unload or load) if not permitted by the current EWM process for the object.
I should say I had to carry out a modification in /SCWM/CL_RFID_SERVICES=>ENCODE_INT. It calls a web service or alternatively a RFM in AII. Since I had no AII (and you might, too if you explore it) I had to plug in my own FM instead of /AIN/PUB_IDCONV_ENCODE. This would be the FM which is able to give information about the EPC in the tag and can encode the data EPC Gen2 conformant (as explained in the first functional part of the blog. There is another FM which I didn’t need for that test but you would need it for end-to-end testing: /AIN/PUB_IDCONV_ENCODE_NUMGEN.
Now EWM often expects EPC data to be already persistent in above tables (unless we would create them in a process in the warehouse). And that is where the inbound delivery comes into play. You can submit EPC data already through a dispatch advise (ASN) into EWM. From a business process point that would be a supplier working with (or supporting your) RFID setup and that delivers EPC data during the outbound process to support your inbound process.
In later versions of DELVRYxx IDoc type you will find EPC support. An example for an ASN to create an inbound delivery in ERP (and consecutively in EWM) is below.
I didn’t look into the outbound process for that test.
This field – although aforementioned documentation exists – didn’t find much attention through functional-technical blogs yet. I hope this contributes a little to making it more known in the consulting community.
What do you think about it? Can you contribute more insights? It would be great to gradually improve the quality of this blog!
List of references