Skip to Content
Technical Articles

Cloud Robotics for SAP-Extended Warehouse Management, Part 2

What can you do with Cloud Robotics? How does it work? This blog describes the High-level Architecture of Cloud Robotics and lists supported EWM scenarios.

The previous blog introduced the open source solution that integrates collaborative robots with SAP Warehouse Management. The architecture is robot-vendor-agnostic and covers a range of use cases even for heterogeneous fleets, combined with state-of-the-art IT strategy and governance. Users can easily integrate warehouse robots into SAP-EWM processes and add more robots in minutes.

Why traditional robot integration is so expensive

With the advent of autonomous edge devices such as robots there are business processes, which are executed partly in the business application and partly on the edge device. There is no generalized approach for the distribution of application components between the business application and the edge such that it could be applied independent from a specific use case.

Therefore, connecting edge devices with business applications such as EWM is always done on a project basis and for a specific use case. Such projects are lengthy and expensive. Their results can hardly be re-used for different use cases.

Connectivity between the edge device and the business application poses additional problems:

  • Reliability: When a connection between the edge device and the business application breaks, the edge device needs to stop, because it would not know about the next steps
  • Bandwidth: Edge devices sensing their environment need to transmit large amounts of data for processing to the business application. In some cases, this exceeds available bandwidth.

Leveraging Kubernetes for quick and easy integration

Distribution of application components is made in line with the business role of the edge device, thus, with the role it plays in a business process. The software on the edge device manages assigned order, executes and updates them. The latter is called „Federation“ and happens across cloud application and edge device.

To do so we install the application components using docker containers. They contain functions and feature, which may also be part of the business application; more specifically:

  1. Execution of orders, which the cloud application assigned to the edge device; administration of these order according to order completion
  2. Administrative functions such as logon and logoff to the cloud, status information about the edge device to be shared with the cloud application

A few more details on (1): The process logic on the edge reflects the process logic in the cloud. Parts of the end-to-end process are in the cloud, others on the edge device. This means that the edge device manages orders in line with the process logic in the cloud application. An order can be both in the cloud and on the edge device, which can update each other (see “Federation” above). The update does not need to be instantaneous, it can also happen in so-called “near real-time”, when delays in the order of several seconds to minutes is acceptable.

There are major advantages:

  • SAP’s software is independent from a given, often proprietary software/hardware stack for the edge device
  • The distribution of components for the application software is structured in line with the role the edge device plays in the business process. The software component on the edge device manages and updates orders from the business perspective of the edge device.

A robot can be integrated within minutes with EWM, simply by downloading the application software. This can be automated using application management tools like Kubernetes (see https://googlecloudrobotics.github.io/core/concepts/app-management.html)

When business processes change, they can be propagated with ease to the edge device by simply downloading the corresponding new tasks. The same applies when porting the edge device to a different environment.

The example below illustrates this with a warehouse management system as cloud or on-premise business application and transportation robots as edge devices:

  • Traditional approach: The robot receives detailed commands from the warehouse management system (WMS); the warehouse order stays in the WMS. During execution the robot sends back status information to the WMS, which calculates from this the status of the warehouse order and updates it. An integration like this typically is highly individual considering the robot vendor and the specific requirements of each use case, effectively taking weeks or months.
  • SAP Cloud robotics: EWM assigns the robot to the warehouse order and copies the order onto the robot. During execution the robot continuously updates its local copy of the order which is synchronized with the order version in the WMS Order

The graphics below outlines the overall setup, in this case with a MiR robot and describe the tasks for IT:

#          Description IT Task
1 EWM add-on for Cloud Robotics
  • OData Interface, feeding GCP with EWM orders and tasks as well as task confirmations
  • Resource extension: Robot as a resource for transportation or picking
  • Process extension, for Pick-pack-and-pass scenario: Handling unit for picking task is assigned to the robot
Add-on needs to be implemented in SAP-EWM
2 SAP Cloud Connector
  • A program, which connects SAP EWM with the SAP Cloud Platform. It serves as a router for OData services
Install, if missing
3 SAP Cloud Platform ·

    • OData provisioning service, an OData endpoint on the internet or on the SAP Cloud
Install, if missing
4 Google Cloud Platform

 

Supported Scenarios

Warehouse operators get ready-to-run EWM scenarios, which work with robots from hundreds of vendors as easy as plug-and-play. Out-of-the-box, the solution supports 3 EWM scenarios: Cross-docking, Put-away, and Pick-pack-and-pass.

Cross-Docking

  1. Operator packs cross-docking items on trolleys at goods receipt
  2. Full trolleys are transported by autonomous robots from the goods receipt zone to the goods issue zone
  3. Empty trolleys are transported back to the goods receipt zone

Put-away

  1. Operator packs items on trolleys at goods receipt
  2. Robots bring full trolleys into a free space of a storage rack
  3. Trolleys are collected from storage racks by robots when they are empty

Robot enabled Pick-Pack-and-Pass

  1. Robot drives to source bin of a transport order
  2. Picker scans robot to get his picking task
  3. After picking confirmation robot continues to next source bin
  4. When all picking tasks were confirmed, robot transports item to Goods Issue

Other popular EWM scenarios are supported, too. Alternatively, the solution is likely to support a scenario with little additional effort.

How Users Benefit

SAP Cloud Robotics is quick to implement and requires no additional licensing. It gives EWM customers an easy, low-risk entry into agile warehouse robotics. The solution runs and optimizes heterogenous fleets and material flows. It provides a new degree of ad-hoc scalability. To meet peak demand, users can integrate additional robots within minutes.

As already mentioned, the solution is provided as an Open Source. The Google part of the Code is here and the SAP part is here.

This is the second blog of a series that will provide an introduction to Cloud Robotics. Click here for the first part.

Go to part 3

 

4 Comments
You must be Logged on to comment or reply to a post.
  • Hi Albrecht,

    Thanks for the second part.

    I would like to understand the roles of each application, especially on synchronization process you mentioned. Sometimes, robots (tend to) forget orders or it gets lost during transmission. In the architecture you draw, which solution is responsible to send the order again or get feedback if synchronization happened successfully or not? Is it still EWM or did you give this to other application?

    Moreover, do you expect robots to store all the messages you sent or do you store them in cloud applications and synchronize one by one when robot is free?

    Thanks in advance.

    Best regards

    Serhan

    • Hi Serhan,

      our messages/orders don’t get lost. The mechanism behind it is custom resources, which is an extension of Kubernetes. There is also a cloud part, called Order Manager, that distributes the orders accordingly to the robots. Based on custom resources the robots/edges continuously sync with the Order Manager – as long as there is connectivity. This mechanism also allows us to organise the robots properly when orders/tasks have been processed. So, storing of the orders/messages is not needed. The robot can even be in areas where there is no connectivity to continue processing the orders and sync back with the Order Manager which will report back to EWM.

      Best,
      Rudi

  • Hi all (Albrecht, Nemrude, …) 🙂

     

    I have a couple of questions regarding the solution

    1. If it’s all open source, will there be “hidden fees”?
    2. Who will provide (professional) support in a logistics domain where failures may pile up to severely affect warehouse performance
    3. What about the statement “pre alpha” statement on Google Cloud Robotics Core? https://github.com/googlecloudrobotics/core
    4. What about network connection of the edge devices (read “robot”) to Google Cloud Platform (Google Cloud Robotics) for federation / cr-sync? Would really every edge device need to reach GCP

    Many thanks and kind regards

    Jens

    • Hi Jens,

      Thanks for asking!

      (1) It is all open source except

      • SAP EWM, which always required a license. No change.
      • The same applies to SAP Cloud Connector and SAP Cloud Platform

      Additional cost:

      • Google or other hyperscalers will charge a subscription fee for using their respective cloud platform
      • the robot will hardly come for free

      (2) Professional support comes from E.g., the SAP consulting organization. The group for EWM consulting has some experts.

       

      (3) “Support is currently limited to a small set of early access partners.” – I guess this is what you refer to. We are one of these partners.

      (4) Yes. To be more precise, edge devices do not necessarily need to connect to GCP but to  the Cloud Kubernetes Cluster. The setup introduced here  assumes a deployment in GCP, but it would be possible to deploy somewhere else.