Cloud Robotik

Abstract

The shift towards eCommerce and increased consumer demand for customized products and services along with hardware-related improvements, has been driving significant changes in supply-chain processes. To cope with those different challenges, especially in shop floors, warehouses, and increasingly in logistics, automation and collaborative robotics increasingly gain relevance to increase agility and productivity in these domains.

Robotic automation is being held back by the complexity and effort of custom system integration, which is time-consuming and expensive. Today only 20–30% of manufacturing or logistics operations are automated.

We believe that the current Industrie 4.0 initiatives at SAP and Cloud Robotics have the potential to make automation drastically faster and cheaper. While SAP’s engagement in the German Industrie 4.0 Platform is being realized through the Asset Administration Shell implementation to provide an easy way to integrate assets to business processes, Cloud Robotics complements this with a new form of integrating autonomous robots into logistics processes.

In May 2019, Google released Google’s Cloud Robotics Core, an open, cloud-based automation platform for robotics hardware manufacturers, integrators, and software developers. SAP’s focus is the orchestration of robots from different vendors as a fleet for a variety of logistics processes and SAP also released the necessary extensions to work with Google’s Cloud Robotics as open source packages. Cloud Robotics enables users of SAP Extended Warehouse Management (EWM) to quickly deploy and integrate autonomous warehouse robots into their operations and scale ad-hoc.

This article justifies why autonomous robots require a different integration with business applications and describes a new technological foundation for Cloud-Edge-Integration. Subsequently it introduces Cloud Robotics as a solution, compares this with other robotic platforms and describes an implementation.

Einführung

Seit Jahrzehnten sind Industrieroboter zur Automatisierung industrieller Serienfertigung im Einsatz. Autorisierte Systemintegratoren implementieren kundenindividuelle Lösungen in der Automobil‑, Elektronik‑, Lebensmittel- und Pharmaindustrie. Die Integration von Robotern in die Unternehmens-IT ist mehr als doppelt so teuer wie die Roboter selbst. Laut einer Studie des Fraunhofer IPA wurden 2016 mit Robotern US$ 13 Mrd. umgesetzt, mit Systemintegration dagegen US$ 28 Mrd.1.

In den vergangenen 10 Jahren gewann eine neue Klasse sogenannter kollaborativer Roboter an Bedeutung. Fortschritte in Software und Infrastruktur ermöglichen immer leistungsfähigere und intelligentere Maschinen, die Seite an Seite und oft in enger Zusammenarbeit mit Menschen arbeiten. Dank maschinellem Sehen, Verarbeitung natürlicher Sprache und andere Anwendungen aus dem Machine Learning sowie moderner Sensorik können Roboter die Welt um sich herum erfassen und auch in ungeplanten Situationen angemessen agieren. So transportieren etwa Lagerroboter Waren vom Wareneingang zu den Regalen oder umgekehrt von den Regalen zum Warenausgang. Be- und entladen werden sie gewöhnlich von Menschen, mit denen sie den Arbeitsraum teilen. Da sind keine Käfige, die Menschen vor Robotern schützen. Diese Roboter scannen ihre Umgebung und finden selbständig ihren Weg durchs Lager. Noch weiter geht z. B. Magazinos mit dem Toru-Roboter, der Gegenstände in der Größenordnung von Schuhkartons zusätzlich greifen und stapeln kann.

Außerdem ist diese Klasse von Robotern oft einfacher zu programmieren als traditionelle Industrieroboter. Die Preise kollaborativer Roboter sind in den letzten zehn Jahren deutlich gefallen. Ein lebendiger Markt mit hunderten unterschiedlichen Anbietern macht Roboter-Automatisierung auch für kleine und mittlere Unternehmen erschwinglich.

Die jährlichen Ausgaben 2020 für Roboter-Hardware, -Dienstleistungen und -Software erreichen laut einem IDC-Bericht 112,4 Mrd. US-Dollar bei einem jährlichen Wachstum von 19,8 % bis 20232. Dieses Wachstum wird erneut zu mehr Innovation, niedrigeren Kosten und größerer Akzeptanz führen. Eine aktive Open Source-Community fördert dieses Wachstum mit Software- und Hardwareprojekten, zu denen insbesondere die ROS-Plattform (Robot Operating System) gehört. Sie hilft akademischen Einrichtungen und Unternehmen, Roboter besser, schneller und billiger zu entwickeln.

Cloud Computing ist die nächste Evolutionsstufe, speziell in Kombination mit dem Internet der Dinge: Damit müssen Roboter nicht alle Software lokal bereithalten, die sie eventuell brauchen. Mithilfe der Cloud können Geräte über ihre digitalen Zwillinge Daten und Programme teilen. Sie können Statusinformationen austauschen, etwa der Ladezustand der Batterie oder plötzlich auftretende Hindernisse oder sich koordinieren. Über die Cloud kann aber auch Software verteilt werden.

Einige Probleme bestehen beim Einsatz kollaborativer Roboter fort:

• Vertikal integrierte Software Stacks: Proprietäre Software-Layer, Werkzeuge, Programmierumgebungen und Cloud-Dienste

• IT-Administration und Governance werden durch zusätzliche Stacks komplexer

• Integration mit ERP oder Lagerverwaltungssystemen sind teuer und dauern lange.

Ziel dieses Artikels ist einen neuen Weg aufzuzeigen, wie mittels Cloud-Technologien autonome Roboter deutlich schneller und einfacher als bisher mit betriebswirtschaftlichen Anwendungen integriert werden können. Dies wird quantifiziert und in einer ersten Implementierung belegt.

Methodik

Abschn. 3 belegt, dass die Prozessintegration von Industrierobotern deutlich teurer ist als die Robotik-Hardware. Zwar senken kollaborative Roboter die Eintrittsbarriere in die Robotik und gewannen so neue Einsatzgebiete in Industrie und Handel. Am größten Kostenblock, der Systemintegration, ändern kollaborative Roboter aber wenig. Abschn. 4 stellt das Cloud–Edge Integrationskonzept von Cloud Robotik dar. Es entstand aus einer Kooperation zwischen Google und SAP. Als Erfinder von Kubernetes bringt Google eine neue Perspektive auf Roboter, nämlich als Cluster-Knoten auf die Kubernetes Docker Container verteilen kann, unabhängig von der darunterliegenden Hardware. Inhalt dieser Container sind Lagerverwaltungsprozesse, die eine Domäne von SAP sind. Daraus entstand Cloud Robotik. Abschn. 4 vergleicht es mit traditionellen Integrationskonzepten und nennt derzeit unterstützte Szenarien. Google und SAP haben das Gesamtsystem mit MIR3-Robotern in einem gemeinsamen Robotik-Labor ein halbes Jahr lang getestet.

Abschn. 5 beschreibt Anwendungsbereiche für Cloud Robotik. Cloud Robotik im Verbund mit SAP-Lösungen stellt Abschn. 6 dar und beschreibt die Ergebnisse einer Implementierung im Lager eines Großhändlers.

Einen Ausblick auf die weitere Entwicklung in Richtung einer herstellerunabhängigen ad-hoc Prozessintegration gibt schließlich Abschn. 7.

Die Evolution industrieller Robotik

Industrielle Automatisierung

Mit Roboter-Hardware zur industriellen Automatisierung wurden 2016 weltweit Umsätze in Höhe von 13 Mrd Dollar erzielt4. Der Markt wurde in den letzten Jahrzehnten von einigen wenigen Hardware-Anbietern dominiert, namentlich Fanuc, Yaskawa, ABB, Kawasaki und Kuka (Abb. 1).

Abb. 1.

Markt für Industrielle Automatisierung (Robotik)

Systemintegration von Automatisierungslösungen ist der deutlich größere Markt. Kunden zahlten für die Integration robotergestützter Automatisierungslösungen doppelt so viel Geld wie für die Hardware zur Automatisierung. Beide Segmente wachsen jährlich mit etwa 15 % (CAGR5).

Die Roboter werden von Systemintegratoren in den Markt gebracht, die maßgeschneiderte Automatisierungslösungen auf Projektbasis implementieren und ihre Preise nach Aufwand (Zeit und Material) gestalten. Die Lösungen machen sich hauptsächlich bei stark standardisierten und hochvolumigen Prozessen großer Industrieunternehmen bezahlt. Die kundenindividuelle Natur der Lösungen bringt Kunden in ein Abhängigkeitsverhältnis zu ihren Systemintegratoren und Roboterherstellern. Wollen Sie den Systemintegrator wechseln oder Roboter eines anderen Herstellers hinzufügen, ist das nur mit hohem Aufwand möglich.

Kollaborative Roboter

Im vergangenen Jahrzehnt haben sich kollaborative Roboter zu einer neuen Klasse von Robotern entwickelt, die Seite an Seite mit Menschen ohne Schutzkäfig arbeiten können.

Kollaborative Roboter unterscheiden sich in mehrfacher Hinsicht von ihren industriellen Pendants (vgl. Abb. 2):

• Sie arbeiten sicher neben Menschen dank aktueller Sensortechnologie. Dazu zählen Lasersensoren zur Abstands- und Geschwindigkeitsmessung, sogenannte Lidars6, in mobilen Robotern und Drehmomentsensoren in Manipulatoren.

• Verwendung einer modernen Software-Plattform. Die große Mehrzahl verwendet Linux und das Open-Source-ROS als Middleware.

• Deutlich einfacher zu implementieren als Industrieroboter

Abb. 2.

Technische Entwicklungen, die zu einer neuen Klasse von Robotern führten

Mit einem weltweiten Umsatz von US$ 4,7 Mrd. (2016) ist der Markt für kollaborative Roboter kleiner als der für Industrieroboter. Der Markt wächst jedoch schneller, mit einer prognostizierten durchschnittlichen jährlichen Wachstumsrate von 20–25 % bis 2020.7

Hersteller kollaborativer Roboter positionieren sich im Markt mit zwei unterschiedlichen Strategien:

• Einige Akteure verfolgen eine vertikal integrierte Strategie und bieten Lösungen direkt für ihren Zielmarkt an. Beispiele für diese Kategorie sind Fetch Robotics und Magazino.

• Andere Unternehmen verwenden ein Modell, das dem der Industrierobotik ähnelt, und arbeiten mit Integratoren zusammen. Beispiele dafür sind Mobile Industrial Robots (MIR) und Universal Robots.

eCommerce und Industrie 4.0 als Treiber für Robotik

Zwei transformative Trends in Industrie und Handel treiben die steigende Nachfrage nach Roboterlösungen.

eCommerce hat den Handel verändert. Die Distribution wird von Verbrauchern, die Waren in Einzelhandelsgeschäften entnehmen, verlagert zu Dienstleistern in Distributionszentren. Dieser Trend hat einen Punkt erreicht, an dem die Nachfrage nach Lagerarbeit das Angebot an verfügbaren Arbeitskräften übersteigt. Erschwerend kommt hinzu, dass Lager und Distributionszentren in geographischer Nähe zu Konsumenten liegen müssen. Off-shoring, also Verlagerung ins kostengünstigere Ausland, ist keine sinnvolle Option. Lagerarbeit ist auch körperlich belastend und kann dauerhafte Gesundheitsschäden verursachen. Für weiteres Wachstum fehlen Arbeitskräfte. Deswegen werden Roboter für Lager und Distributionszentren immer mehr nachgefragt.

Kern von Industrie 4.0 ist u. a. die Digitalisierung von Fertigungs- und Lieferkettenprozessen. Sensorgesteuerte Anlagen ermöglichen Industrieunternehmen mehr Echtzeit-Einblicke in ihre Prozesse, was wiederum kürzere Rückkopplungsschleifen und agilere Abläufe ermöglicht. Die Robotik spielt hier eine Doppelrolle: Kollaborative Roboter dienen als Aktoren in einem Regelkreis. Darüber hinaus erfassen ihre bordeigenen Sensoren Aspekte der Umgebung, die nicht ohne Weiteres digitalisierbar sind: Objekte wie Regale, Paletten, Kisten, Behälter oder Produkte in der Montage oder im Lager. So helfen Sensordaten von Robotern – RGB-Bilder oder 3D-Punktwolken –, ein digitales Modell der physischen Betriebsumgebung zu erstellen oder zu aktualisieren.

Cloud Robotik

Cloud Robotik ist eine quelloffene Plattform, um autonome Systeme in Fertigung und Logistik, insbesondere kollaborative Roboter, nahtlos mit betriebswirtschaftlichen Anwendungen für Fertigung und Logistik zu integrieren. Die Plattform soll wiederverwendbare Komponenten zugänglicher machen und ersetzt oder reduziert den Bedarf nach kundenspezifischen, projektbasierten Lösungen:

• OEM-agnostische Architektur – maximale Flexibilität und Wahlfreiheit bei der Auswahl von Robotern

• Herstellerübergreifende Flotten, um unterschiedlich spezialisierte Roboter koordiniert einzusetzen – Automatisierung nach Bedarf

• Sofort einsatzbereite Integration mit SAP Extended Warehouse Management und vordefinierte Szenarien

• IT-Governance, die automatisch die Roboter einschließt

Cloud Robotik funktioniert mit autonomen Transportrobotern der meisten Anbieter bei keiner oder geringer Anpassung und kann heterogene Flotten steuern. Anwender der Lösung gewinnen strategische Flexibilität und einen kostengünstigen Einstieg in die Robotik:

• Automatisierung kann in Bereiche vordringen, in denen bisher keine Roboter eingesetzt wurden, insbesondere nicht-wiederkehrende und assistierende Aufgaben.

• Automatisierung mit Robotern wird auch für kleine und mittlere Unternehmen attraktiv, die sich in der Vergangenheit keine Roboter leisten konnten.

• Die Lösung skaliert ad-hoc. Betreiber von Robotern können in Minuten weitere Roboter, die kurzfristig angemietet wurden, hinzufügen und so ihre Maschinennutzung optimieren. Damit lassen sich Bedarfsspitzen wie an Cyber-Monday, Black-Friday oder zu Beginn der Covid-19-Krise ohne zusätzliche Investitionen decken.

• Betreiber von Robotern reduzieren die Abhängigkeit von ihren Herstellern und können Flotten von mehreren Anbietern ohne den zusätzlichen IT-Aufwand, der sich aus einer Vielzahl proprietärer Software-Stacks ergibt, betreiben.

Cloud-Edge Integration statt traditioneller Integration von Subsystemen

Autonome Systeme sind, wenn sie integriert eingesetzt werden, Teile der Edge eines ERP-Systems, das entweder in der Cloud oder lokal („on premise“) betrieben wird. Aus ERP-Sicht ist eine Maschine – etwa im Sinne der ISA-958 Hierarchie – ein Subsystem, das Befehle aus dem ERP-System erhält und einen Status zurückmeldet. Beispielhaft dafür ist das Materialflussystem (MFS) der SAP Lagerverwaltung SAP-EWM. Sie verbindet die Lagerverwaltung z. B. mit einem Förderband. Der Nachrichtenaustausch über MFS besteht aus kurzen, einfachen Nachrichten, sogenannten Telegrammen, mit denen das Lagerverwaltungssystem bei Latenzzeiten im Millisekunden-Bereich einfache Kommandos an das Förderband schickt. Das Protokoll der Kommunikation hängt von den Spezifika des Subsystems ab, im Beispiel denen des Förderbands. Die Kommunikation gestaltet sich hersteller- und geräteabhängig und wird kundenindividuell implementiert.

Beispiele solch kurzer Kommandos sind, eine Weiche im Förderband nach links zu stellen, damit ein bestimmtes Paket an den richtigen Zielort transportiert wird, oder das Förderband anzuhalten. Für die Kommunikation mit Förderbändern ist das völlig angemessen. Autonome Systeme dagegen erfassen eine komplexe Umgebung, die das Lagerverwaltungssystem nicht kennt, und treffen Entscheidungen selbstständig. Eine Telegrammkommunikation ist wegen der Autonomie nicht sinnvoll.

Die Konnektivität zwischen der betriebswirtschaftlichen Anwendung und einem mobilen Gerät wirft zusätzliche Probleme bei der Zuverlässigkeit von WLAN-Verbindungen auf. Wenn eine Verbindung zwischen dem Edge-Gerät und der Geschäftsanwendung abbricht, muss das Gerät anhalten, weil es den nächsten Prozessschritt nicht kennt. Die WLAN-Ausleuchtung ist in Lagern selten über die gesamte Fläche von guter Qualität. In der Praxis erlebt man gute WLAN-Qualität im Bereich des Warenein- und -ausgangs. In anderen Bereichen ist das Signal stellenweise schwach oder fehlt ganz. Mobile Systeme, die auf Nachrichtenaustausch mit kurzen Latenzen angewiesen sind, können in solchen Bereichen nicht zuverlässig arbeiten.

Kollaborative Roboter beziehen ihre Autonomie aus der Rechenleistung und Sensorik, die ihnen zur Verfügung steht. Es bietet sich daher an, Geschäftsprozesse, die sie ausführen auf den Robotern ablaufen zu lassen. Diese neue Form der Integration wird bereits in proprietärer Form von Roboterherstellern angeboten. So integrieren Hersteller autonomer Lagerroboter ihre Produkte mit SAP-EWM häufig über sogenannte IDOCs. Das sind elektronische Dokumente mit einem vorgegebenen Format für den Datentransfer zwischen SAP-Systemen und nicht-SAP Systemen.

Zu den Vorteilen dieses Ansatzes zählt neben und der umfangreichen Kontrolle über die Übertragung bei IDOCs9 auch, dass IDOCs über SAP-Release Zyklen unverändert bleiben. Aus Sicht des Anwenders hat die Integration von Robotern mit IDOCs aber auch Nachteile

• Die Gestaltung der Integration variiert von Roboterhersteller zu Roboterhersteller und hängt auch vom konkreten Einsatz ab. Sie ist proprietär, nicht universell. Sollen Roboter eines weiteren Herstellers dazukommen, dann benötigt der Anwender eine weitere Integration.

• Hersteller autonomer Lagerroboter stellen oft ein eigenes, einfaches Lagerverwaltungssystem bereit, das IDOCs aus der SAP Lagerverwaltung empfängt und verarbeitet. Der Anwender hat dann in seinem Lager zwei Lagerverwaltungssystemen. Die konkrete Implementierung muss die Aufgaben zwischen der SAP-Lagerverwaltung und der des Roboterherstellers aufteilen. Das führt zu Brüchen im Prozess und erschwert Optimierungen des Warenflusses im Lager. Verfügt das Lager über weitere Transportsysteme wie etwa ein Förderband oder Aufzüge, dann entsteht ein Gesamtsystem, das für Endanwender kompliziert ist.

Ein verallgemeinernder Ansatz fehlt bisher. Das führt zu oft teuren Integrationsprojekten, die – egal ob mit IDOCs oder mit MFS – je nach Umfang eines Projekts bei mehreren Monaten beginnen und bis in die Größenordnung von 18 Monaten reichen. Zu diesen Zahlen gibt es keine belastbaren, veröffentlichten Untersuchungen10, sie sind vielmehr das Ergebnis eigener Befragungen von Anwendern und EWM-Beratern.

Dazu kommt, dass die technische Lösung eines Projekts selbst innerhalb des gleichen Unternehmens nur selten wiederverwertbar ist.

Basis-Komponenten von Cloud Robotik

Cloud Robotik entstand in einer Zusammenarbeit zwischen SAP und Google und umfasst eine Reihe verbundener Softwarekomponenten:

• Cloud Robotik Core ist die offene Plattform, die Roboter sicher mit der Cloud verbindet. Sie ermöglicht die Verteilung containerisierter11 Software-Assets an Roboter mithilfe einer Kubernetes-Laufzeitumgebung12. Weitere Aufgaben des Cloud Robotik Core sind Upload und Konsolidierung von Protokolldaten, Metriken und Sensordaten. Cloud Robotik Core ist in den Verwaltungsservice Stackdriver, den Eventmonitor Prometheus und das Analyse- und Visualisierungssystem Grafana (alle quelloffen) integriert und bietet robuste Systemverwaltungsfunktionen. Cloud Robotik Core stellt in standardisierte Weise und unter Verwendung ausgereifter und offener Cloud-Technologien zentrale Dienste für die Infrastruktur zu Verfügung.

• Anwendungen: Cloud Robotik Core definiert eine App als eine Reihe containerisierter Dienste, die auf dem Roboter, on-premise oder in der Cloud ausgeführt werden können. Eine App kann zum Beispiel in einer 2‑tier-Konfiguration (unten rot dargestellt), in einer 3‑tier-Konfiguration (grün) oder als eigenständiges Modul auf dem Roboter (blau) laufen. Apps können auch von Drittanbietern bereitgestellt werden (gelb dargestellt) (Abb. 3).

Abb. 3.

Cloud Robotik Core im Überblick

Integration Kollaborativer Roboter mit der Lagerverwaltung

Für eine Lagerverwaltung wie SAP-EWM sind kollaborative Roboter Transportressourcen, die Lageraufträge ausführen. Cloud Robotik dient hier als Abstraktionsschicht, die SAP-EWM erlaubt, mit Robotern unterschiedlicher Hersteller zu kommunizieren. Die Lagerverwaltung orchestriert Arbeitsabläufe in der physischen Welt, indem sie Aufgaben denjenigen Ressourcen – oder Kombinationen von Ressourcen – zuweist, die dafür am besten geeignet sind. Sie kann mit Cloud Robotik auch horizontal Flotten skalieren.

Kubernetes als Grundlage für eine Cloud-Edge Integrationsarchitektur

Kubernetes automatisiert die Verteilung von Software auf Geräte an der Edge. Grundsatz für die Verteilung ist, dass ein Gerät an der Edge die Anwendungskomponenten erhält, die zu seiner Rolle passen, also zu den Aufgaben, die das Gerät im Geschäftsprozess übernimmt. In Fall von Cloud Robotik führen die Roboter Lageraufträge aus. Sie erhalten die Anwendungskomponenten, die sie für die Ausführung von Lageraufträgen benötigen. Beispiele für solche Komponenten sind die Ausführungsbestätigung für eine Lageraufgabe oder die Verwaltung der Reihenfolge der Aufgaben. Die Verteilung wird als „Federation“ zwischen Cloud und Edge bezeichnet.

Dazu installiert Kubernetes die Anwendungskomponenten mit Hilfe von Docker-Containern. Sie enthalten im Wesentlichen folgende Funktionen und Merkmale:

1. Ausführung von Aufträgen, die die Cloud-Anwendung dem Gerät an der Peripherie („Edge“) zugewiesen hat; Verwaltung dieser Aufträge

2. Administrative Funktionen wie An- und Abmeldung in der Cloud, Statusinformationen über das Edge-Gerät, das mit der Cloud-Anwendung gemeinsam genutzt werden soll

Einzelheiten zu (1): Die Prozesslogik auf dem Roboter passt mit der Prozesslogik in der Cloud zusammen. Dafür sorgt die Verteilungsregel (s. oben). Teile des End-to-End-Prozesses führt das Lagerverwaltungssystem zentral aus, andere der Roboter an der Edge. Das bedeutet, dass der Roboter Aufträge in Übereinstimmung mit der Prozesslogik in der Cloud-Anwendung verwaltet. Ein Auftrag kann sich sowohl in der Cloud als auch auf dem Edge-Gerät befinden, die ihn jeweils aktualisieren können (siehe „Federation“ oben). Die Aktualisierung muss nicht in Echtzeit erfolgen. Latenzen in der Größenordnung von einigen Sekunden bis Minuten sind akzeptabel und behindern nicht das Gesamtsystem.

Der Ansatz hat eine Reihe von Vorteilen:

• Anwendungssoftware für Geräte an der Edge kann unabhängig von einem proprietären Software-und Hardware-Stack erstellt werden.

• Die Verteilung der Software, also welche Komponenten der Software zentral ausgeführt werden und welche auf dem Roboter, wird von den Fähigkeiten des Roboters und seiner Rolle im Arbeitsablauf bestimmt. Die Verteilung ist damit intuitiv nachvollziehbar. Kann der Roboter etwa auch Ware zählen oder wiegen, dann kann er auch Inventuraufgaben übernehmen und erhält dafür Software.

• Die Google Cloud Plattform (oder die Plattform eines anderen gewählten Hyperscalers) adressiert auch IT-Sicherheit und Corporate Governance. Jedes Edge-Gerät – und damit jeder Roboter – wird zu einem Kubernetes Cluster. Der Zugang erfolgt mit den Usern, die für die Google Cloud Plattform definiert wurden. Hyperscaler gelten als weltweit führend im Bereich IT-Sicherheit13. Eindringlinge müssten die Sicherheit dieser Plattformen überwinden, was erheblich schwieriger sein dürfte als bei dem, was die meisten Organisationen Eindringlingen entgegensetzen.

In der Praxis bedeutet das, dass ein Roboter innerhalb weniger Minuten in SAP-EWM integriert werden kann. Dazu definiert man den Roboter als Kubernetes-Cluster. Kubernetes installiert danach automatisch die Anwendungssoftware auf dem Roboter.

Das nachstehende Beispiel veranschaulicht die Unterschiede zwischen dem herkömmlichen Ansatz der Roboterintegration und diesem Ansatz. Als Beispiel dienen ein Lagerverwaltungssystem, das in der Cloud oder on-premise betrieben wird, sowie Transportroboter als Geräte an der Edge:

• Herkömmlicher Ansatz: Der Roboter erhält detaillierte Befehle vom Lagerverwaltungssystem (LVS); der Lagerauftrag liegt im LVS. Während der Ausführung sendet der Roboter Statusinformationen an das LVS zurück, das daraus den Status des Lagerauftrags errechnet und ihn aktualisiert.

  Eine solche Integration ist in der Regel kundenindividuell, wenn man den Roboterhersteller und die spezifischen Anforderungen des jeweiligen Anwendungsfalles berücksichtigt. Die Implementierung dauert mehrere Monate.

• SAP Cloud-Robotik: SAP-EWM weist den Lagerauftrag einem Roboter zu und kopiert den Lagerauftrag auf den Roboter. Während der Ausführung aktualisiert der Roboter kontinuierlich seine lokale Kopie der Bestellung, die mit der dem Lagerauftrag in EWM synchronisiert wird.

  Eine solche Integration verwendet nur Standardsoftware und ist, was den Integrationsteil angeht, innerhalb von Stunden oder Tagen machbar.

Die folgenden Grafiken skizzieren den Gesamtaufbau, in diesem Fall mit einem MiR-Roboter, und beschreiben die Aufgaben für die IT für den Fall einer Erstimplementierung (Abb. 4):

Abb. 4.

Gesamtaufbau SAP-EWM mit Robotikintegration

Komponenten von Cloud Robotik und ihre Implementierung nennt Tab. 1.

Tab. 1.

Komponenten von Cloud Robotik

#	IT-Komponente	Beschreibung	Implementierung
1	EWM add-on für Cloud Robotik	Schnittstelle überträgt Lageraufträge an Cloud Robotik Definition der Roboter als Ressourcen z. B. für Lagertransport	SAP-EWM um das Add-on erweitertn
2	SAP Cloud Connector	Standardprodukt, das hier EWM mit der Cloud Plattform verbindet und als Router für OData Services fungiert	Installieren, falls noch nicht vorhanden
3	SAP Cloud Plattform	OData Provisioning Service, ein OData Endpunkt im Internet oder der SAP Cloud	Installieren, falls noch nicht vorhanden
4	Google Cloud Plattform	Hier kommen auch Kubernetes-fähige Plattformen anderer Hyperscaler infrage	–

Wenn sich Geschäftsprozesse ändern, können sie durch einfaches Herunterladen der entsprechenden neuen Aufgaben problemlos auf den Roboter übertragen werden. Ebenso problemlos ist die Portierung von Robotern in eine andere Umgebung, etwa in ein anderes Lager mit anderen Prozessen, sofern auch dort Cloud Robotik im Einsatz ist.

Unterstützte Logistikszenarien im Lager

Cloud Robotik für SAP-EWM hält sofort einsetzbare Szenarien für die Lagerlogistik bereit. Sie funktionieren unabhängig vom Roboterhersteller. Standardmäßig unterstützt die Lösung 3 EWM-Szenarien: Cross-Docking, Einlagerung und Pick-pack-and-pass.

Pick-pack-and-pass ist ein Entnahme- oder Einlagerungsvorgang in einem Lager, das in mehrere Bereiche aufgeteilt sind, in denen jeweils Lageristen arbeiten. Für einen Kommissioniervorgang fährt ein Transportfahrzeug14 die Bereiche nacheinander ab. In jedem Bereich belädt ihn der Bereichslagerist mit Ware, bevor das Fahrzeug zum nächsten Bereich fährt. Am Ende fährt das Transportfahrzeug die kommissionierte Ware zum Warenausgang.

Tab. 2 beschreibt die Szenarien, die Cloud Robotik für die Lagerhaltung bereithält. Weitere Szenarien sind realisierbar.

Tab. 2.

Bereitgestellte Szenarien für die Lagerverwaltung

Szenario	Beschreibung
Cross-Docking	1. Lagerist im Wareneingang packt Ware auf einen Wagen. 2. Roboter bewegt Wagen zum Warenausgang 3. Lagerist im Warenausgang entlädt Roboter 4. Roboter bewegt leeren Wagen zurück in den Wareneingang
Einlagerung	1. Lagerist im Wareneingang packt Artikel auf einen Wagen 2. Roboter bewegt volle Wagen auf einen freien Platz im Lager. Ware auf dem Wagen wird mit der Zeit händisch entnommen
Roboter-unterstütztes „Pick-Pack-and-Pass“	1. Roboter fährt zum ersten Lagerbereich und trifft dort den Bereichslageristen. 2. Mit ihm fährt er die für den Lagerauftrag relevanten Lagerplätze ab und wird beladen. Der Lagerist bestätigt jede Warenentnahme. 3. Wurden alle Artikel aus dem Bereich beladen, fährt der Roboter zum nächsten Lagerbereich und geht vor wie unter (2). 4. Wurden alle relevanten Bereiche abgefahren, bewegt der Roboter die Ware zum Warenausgang

Andere populäre EWM-Szenarien werden ebenfalls unterstützt, ggf. ist ein geringer Zusatzaufwand notwendig.

Cloud Robotik reduziert so deutlich den Aufwand für Bereitstellung, Einführung und Skalierung autonomer Systeme und stellt dabei eine Form von Interoperabilität zwischen Lagerrobotern unterschiedlicher Hersteller bereit.

Vergleich der Integrationsansätze

Tab. 3 vergleicht die herkömmlichen Ansätze einer SAP-EWM Integration über die Materialfluss-Schnittstelle MFS und einer Integration über IDOCs mit Cloud Robotik.

Tab. 3.

Vergleich von Ansätzen zur Integration von Materialflusssystemen mit SAP-EWM

	Materialfluss-Schnittstelle MFS	IDOCs	Cloud Robotik
Gegenstand der Integration	Alle Arten von Materialfluss-Systemen, z. B. auch Förderbänder	Alle Arten von Peripherie-Geräten, abhängig von der jeweiligen Transaktion z. B. auch mobile Endgeräte zur Bestätigung einer Warenbewegung	Nur autonome Transportroboter der Intralogistik
Umfang der Integration	Projektspezifisch	Projektspezifisch	3 populäre Szenarien stehen bereit: Cross-Docking, Einlagerung, Pick-pack-and-pass
Qualität der Integration bei Verwendung autonomer Roboter	Einfach: Die gesamte Steuerung liegt im EWM	Oft kompliziert: Lagerverwaltung wird zwischen SAP-EWM und Lösung des Roboterherstellers aufgeteilt	Einfach: Die Lagerverwaltung bleibt im EWM, der Roboter steuert nur Dinge, die EWM nicht steuert, z. B. Details seiner Route
Initial-Aufwand für Integration	Mehrere Monate	Mehrere Monate	Mehrere Tage bis Wochen
Proprietär vs. Quelloffen	Auf OEM-Seite proprietär	Auf OEM-Seite proprietär	Quelloffen
Erweiterungsaufwand für Geräte eines dritten Herstellers	Mehrere Monate	Mehrere Monate	Stunden
Aufwand der Integration	Mittel bis hoch	Mittel bis hoch	Niedrig

Deutlich wird, dass jeder der Ansätze seine Existenzberechtigung hat. Ein Vergleich der Schritte, die nötig sind, um Roboter erstmals mit einem SAP-EWM zu integrieren, erklärt die Unterschiede im Integrationsaufwand15:

Cloud Robotik reduziert hier den Aufwand auf etwas mehr als 20 %, vgl. Tab. 4. Wesentlich deutlicher wird der Vorteil jedoch, wenn der Anwender nun Roboter eines anderen Herstellers hinzufügt, vgl. Tab. 5. Schritte 1 und 3 entfallen für beide Ansätze; der Anwender definiert keine neuen Integrationsszenarien und kann das bestehende Customizing weiterverwenden. Statt 40 Tagen für die Spezifikation rechnen wir hier nur mit 30 Tage und unterstellen, dass Lerneffekte aus der Erstentwicklung 10 Tage Aufwand einsparen. Bei Verwendung von Cloud Robotik entfällt Schritt 2 komplett, die bestehende Plattform kann direkt so mit dem Roboter des neuen Herstellers genutzt werden.

Tab. 4.

Aufwandsvergleich bei Erstinstallation

Schritt	Traditioneller Integrationsansatz: MFS, IDOC	Cloud Robotik
1	Integrationsszenarien und Prozesse definieren: 2 Tage	Integrationsszenarien und Prozesse auswählen: 2 Tage
2	Spezifikation, Entwicklung: 40 Tage	Ggf. Installation SAP Cloud Connector, Zugang zur SAP Cloud Plattform mit OData Provisioning Service: 1 Tag ABAP Code von Cloud Robotik für EWM herunterladen und importieren, Google (oder Azure, AWS) Projekt vorbereiten: 1 Tag
3	EWM Customizing: 3 Tage	EWM Customizing (Lagerbereiche, Ressourcen, etc.): 3 Tage
4	Robotersteuerung: Fahrstraßen, Lagerplätze: 3 Tage	Robotersteuerung: Fahrstraßen, Lagerplätze: 3 Tage
Summe	48 Tage	Aufwand 10 Tage

Tab. 5.

Aufwandsvergleich bei Hinzufügen eines Roboters

Schritt	Traditioneller Integrationsansatz: MFS, IDOC	Cloud Robotik
1	–	–
2	Spezifikation, Entwicklung: 30 Tage	Aufwand entfällt, weil Plattform bereits existiert und mit Robotern des anderen Herstellers funktioniert
3	–	–
4	Robotersteuerung: Fahrstraßen, Lagerplätze: 3 Tage	Robotersteuerung: Fahrstraßen, Lagerplätze: 3 Tage
Summe	33 Tage	3 Tage

Verglichen mit traditionellen Integrationsansätzen reduziert Cloud Robotik den Aufwand auf 9 %.

Natürlich entsteht im Rahmen eines Einführungsprojekts über die Integration zwischen dem Roboter und EWM hinaus noch erheblicher Aufwand: Meist engagiert man einen Systemintegrator, beschafft Roboter, definiert Testfälle führt Testreihen durch, schult Anwender, erstellt eine Dokumentation, transportiert eine Systemkonfiguration vom Qualitätssicherungs- ins Produktivsystem und begleitet den Produktivstart. Diese Aufgaben fallen unabhängig vom gewählten Integrationskonzept an und wurden deswegen in den Vergleichen nicht berücksichtigt.

Zielgruppen für Cloud Robotik

Im Wesentlichen zwei Gründe führten dazu, dass Lagerlogistik als Startpunkt für Cloud Robotik besonders geeignet ist: Technische Reife und Markttrends16.

1. Technische Reife

   • Perzeptionsgesteuerte, autonome Antriebstechnik hat einen Reifegrad erreicht, der die Automatisierung eines erheblichen Teils des Materialflusses mit autonomen mobilen Robotern (AMRs) möglich macht.
2. Markttrends

   • Der Trend im Einzelhandel zum eCommerce steigert erheblich den Bedarf an Automatisierungslösungen.
   • Der Arbeitskräftemangel im Lager- und Logistikbereich nimmt zu, während gleichzeitig das Wachstum im eCommerce zu höheren Produktivitätsanforderungen im Lager- und Logistikbereich führt.
   • Die Arbeitskosten in traditionellen Ländern des „Near-shoring“, in die bisher viele Unternehmen Aufgaben ausgelagert haben, steigen.

Logistikdienstleister und Einzelhändler haben also besonders hohen Bedarf nach Automatisierung. Das macht Lagerlogistik zu einem idealen Startpunkt. Weil autonome mobile Roboter technisch nun so weit sind, diesem Bedarf ein passendes Angebot entgegenstellen zu können, bietet es sich an, mit autonomen Lagerrobotern als Edge-Geräte zu beginnen.

Die überwiegende Mehrheit dieser mobilen Roboter basiert auf einem ROS-Linux-Stack. ROS17 (Robot Operating System) ist eine Open Source Middleware für Roboter, eine Sammlung von Software Frameworks für Software Entwicklung im Bereich Robotik. Es ist nicht im engeren Sinne ein Betriebssystem, basiert aber auf Linux. Die starke Verbreitung von ROS erleichtert den Integrationsaufwand und macht es für Hersteller von Robotern interessanter, in einer Entwicklungs-Community zu Cloud Robotik beizutragen.

Betreiber von Lagern, eCommerce-Händler

Bei Betreiber von Lagern trifft man die folgenden Herausforderungen an:

• Konstant hoher Druck, die Arbeitsproduktivität ohne größere Änderungen an der Lagerinfrastruktur zu erhöhen. Dies ist auch dem Trend zum eCommerce in der Distribution geschuldet.

• Engpässe beim Lagerpersonal

• Kunden erwarten immer häufiger Lieferung am gleichen Tag oder innerhalb der gleichen Stunde

Sobald sich ein Betreiber entscheidet, sein Lager zu automatisieren, stellt er in der Regel die folgenden Anforderungen:

• Zuverlässige Navigation zu Zielen im Lager: Lagerbetreiber erwarten von autonomen mobilen Geräten, dass sie sich in der bestehenden Arbeitsumgebung verlässlich und genau bewegen. Das Umfeld in einem Lager ist dynamisch, da sich das Lagerlayout und die zu handhabenden Materialien häufig ändern.

• Einbettung in die bestehende Infrastruktur: Autonome Lagerroboter müssen sich in einer bestehenden Infrastruktur zurechtfinden. Dazu gehört Wege und Hindernisse, sich bewegende und statische Objekte zu erkennen.

• Schnelle und einfache Implementierung, zuverlässiger Betrieb: Betreiber eines Lagers möchten Lösungen, die leicht implementierbar sind und schrittweise skalieren. Anschließend muss eine Lösung robust laufen.

  Größere Logistikdienstleister etwa passen ihre Prozesse den individuellen Bedürfnissen ihrer strategischen Kunden an. Gleichzeitig sollen diese Prozesse sich nahtlos in das bestehende Lagerverwaltungssystem integrieren.

• Einsatz und Verwaltung heterogener Flotten: Logistikdienstleister möchten Roboter verschiedener Hersteller gemeinsam betreiben, um die für ihre spezifischen Bedürfnisse die beste Lösung zusammenzustellen.

Cloud Robotik in Kombination mit autonomen Lagerrobotern adressiert diese Bedürfnisse wie folgt:

• Navigation: Kollaborative Roboter besitzen gewöhnlich einen SLAM Service (Simultaneous Localization and Mapping). Mithilfe eines Lasers scannen sie vorab Wege im Lager. Im operativen Betrieb können sie dank SLAM plötzlich auftretende Hindernisse erkennen.

• Einbettung in die bestehende Infrastruktur: Nahtlose Integration mit SAP-EWM Prozessen.

• Schnelle und einfache Implementierung, zuverlässiger Betrieb: Implementierung innerhalb von Tagen und Wochen anstelle von Monaten und Jahren. Zusätzliche Roboter lassen sich in Minuten integrieren.

• Einsatz und Verwaltung heterogener Flotten: Der Robot Abstraction Layer (RAL) in Cloud Robotik stellt Funktionen zur Verfügung, die herstellerunabhängig von Robotern genutzt werden. Schnittstellen ermöglichen die Integration mit SAP-EWM und SAP Asset Intelligence Network (AIN).

Wert für Hersteller von Autonomen Robotern

Cloud Robotik setzt voraus, dass Hardware-Hersteller eine Kubernetes-Umgebung auf ihren Robotern unterstützen. Das ist abhängig von ihrem Geschäftsmodell mehr oder weniger interessant. Hersteller kollaborativer Roboter lassen sich nach ihrer Marktstrategie in zwei Gruppen einteilen:

• Cloud Robotik passt sehr gut für Hersteller, die über Systemintegratoren verkaufen, z. B. Mobile Industrial Robots (MIR) oder Universal Robots. Sie sehen ihre Roboter als eine Plattform für eine Vielfalt von Anwendungsfällen in unterschiedlichsten Branchen.

• Hardware-Hersteller wie Fetch oder Magazino bieten vertikal integrierte Lösungen an, die aus proprietärer Hard- und Software bestehen. Ihr Angebot ist ein Managed Service. Damit sind sie sowohl Integrator als auch Betreiber ihrer eigenen Hard- und Software. Eine quelloffene Plattform ist für diese Gruppe nicht unmittelbar relevant. Das kann sich ändern, wenn die Plattform auch eine fertige Integration in Lagerverwaltungssysteme bietet.

Implementierung von Cloud Robotik im Verbund mit SAP-EWM

Cloud Robotik wurde 2020 in der Bechtle AG eingeführt. Bechtle AG ist ein IT-Dienstleister und Großhandelsunternehmen mit € 4,3 Mrd. Umsatz und über 10.000 Mitarbeitern europaweit.18 Das Distributionszentrum in Neckarsulm handhabte im Jahr 2018 etwa 3,117 Mio. Paketen bei 25.000 qm Lagerfläche und erreichte 100 % des Service-Level-Agreements. Bechtle entschied sich für Cloud Robotik, um die Wachstumsstrategie zu unterstützen19. Im regionalen Arbeitsmarkt konkurriert Bechtle u. a. mit Lidl und Audi; in kaum einer Region Deutschlands ist der Mangel an Lageristen höher als in der Region Heilbronn/Neckarsulm. Cloud Robotik als Ergänzung zum bestehenden SAP-EWM bot sich als Lösung an.

Zwei Szenarien (vgl. Absatz 3.5) wurden implementiert, von denen das erste bereits produktiv läuft:

1. Cross Docking von Waren, die direkt vom Wareneingang zum Warenausgang ohne Einlagerung befördert werden

2. Einlagerung: Einlagern mit mobilen Etagenregalen im Mischbereich.

Abb. 5 illustriert die beiden Szenarien auf dem Grundriss eines Teils des Bechtle-Lagers.

Abb. 5.

Grundriss des Bechtlelagers mit zwei Cloud Robotik Szenarien © Bechtle AG

Bechtles Systemlandschaft entspricht im Wesentlichen Abb. 4. Zum Produktivstart kam ein MIR100-Roboter zum Einsatz, der fahrbare Regale („Carts“) bewegt. Der Integrationsaufwand belief sich auf etwa 10 Personentage. Das Gesamtprojektaufwand war höher, weil zusätzliche Aufgaben anfallen, wie im Schlussabsatz von Absatz 3.6 beschrieben. Aufwand entstand auch, weil Bechtle vorher keine Transportroboter im Einsatz hatte. Beispiele für Aufwand jenseits der Systemintegration:

• Wechsel des Cart-Herstellers während des Projekts, weil das Andocken an Carts des ursprünglich gewählten Cart-Herstellers nicht zuverlässig funktionierte

• Ausstattung des Roboters mit zunächst einer, schließlich zwei Lasergeräten, die den Fußbodenbereich vor dem Roboter ausleuchten. Fährt der Roboter ohne Cart bestand die Sorge, dass er aufgrund seiner geringen Bauhöhe von Gabelstaplerfahrern möglicherweise übersehen wird. Die beiden Laserleuchten erzeugen zwei leuchten rote Streifen auf dem Boden etwa 1,5 m vor dem Roboter, die sich zu einem „X“ kreuzen und so das Risiko von Kollision verringern.

• Bestimmung und Schulung einer „Robot-Nanny“, eines innerbetrieblichen Experten für den Roboter

• Abnahme des Roboters durch den innerbetrieblichen Sicherheitsbeauftragten

Bechtle hat auch geprüft, ob der Roboter sich im Vergleich mit seinen Hubwagen mit Fahrern, die bereits im Einsatz sind, lohnt. Aus Vertraulichkeitsgründen sind hier die Kostenwerte nicht aufgeführt, wohl aber die Kostenelemente:

1. Variante „Personal & Hubwagen“: Summe aus Kosten des Mitarbeiters und den Fahrzeugkosten pro Tag. Bei den Fahrzeugkosten fließen neben der Abschreibung auch Wartung, Reparatur und Energie ein.

2. Variante „Autonomer Transportroboter“: Summe aus periodisierten

   • Softwarekosten
   • Fahrzeugkosten
   • Regalkosten
   • Reorganisations- und Projektkosten

Bechtle errechnete daraus eine Ersparnis von 39 % beim Einsatz des autonomen Transportroboters. Dies war nur möglich, weil die Projektkosten gering waren. Bei einer teuren Systemintegration hätte sich ein autonomer Transportroboter möglicherweise nicht gerechnet.

Natürlich hätte Bechtle stattdessen gleich mit einer ganzen Flotte von Robotern auf einmal starten können. Die Einführungskosten würden sich dann auf viele Geräte verteilen und der Business Case wird profitabler. Dies erschien den Verantwortlichen jedoch zu riskant. Gesucht war ein niederschwelliger Einstieg mit einer überschaubaren Investition und entsprechend geringem Risiko. Seitens der Hardware bieten autonome Lagerroboter einen Einstieg bereits für 15.000 bis 30.000 €. Seitens der Systemintegration können Anwender mit Cloud Robotik bei geringem Implementierungsaufwand den Einstieg realisieren.

Erweiterungsmöglichkeiten für Cloud Robotik im Lager

Cloud Robotics ist ein Schritt, die Integration zwischen Anwendungssystemen in der Cloud und Geräten an der Edge einfacher und agiler zu gestalten. Dieser Ansatz lässt sich so erweitern, dass autonome Roboter weitere Aufgaben im Lager wahrnehmen. Erweiterungsmöglichkeiten bieten sich deshalb an, weil Roboter eine Menge Daten sammeln:

• Punktwolkendaten beschreiben den Arbeitsraum der Roboter über die Zeit, wie sie von 2D- oder 3D-Lidars erzeugt werden.

• Hochauflösende Bilder erfassen relevante Aspekte des Arbeitsbereichs, z. B. Produkte in einem Regal.

• Roboter erfassen darüber hinaus die Stärke des WLAN-Signals oder die Umgebungstemperatur.

Maschinelle Lernen kann mit solchen Daten Werte schaffen, die über Automatisierung hinausgehen. Dazu drei Beispiele:

• Inventur: Roboter können en-passant oder als geplante Operation Lagerbestände erfassen und ständig auf dem aktuellen Stand halten. Das vermeidet Fehlbestände und Überbestände. Manuelle, oft teure Inventuren können seltener durchgeführt werden. Cloud-Robotik-Dienste können um AI-Bausteinen wie etwa Googles Vision API dazu erweitert werden.

• Qualität: Qualitätsprobleme führen zu Kundenreklamationen und sind wesentliche Kostentreiber in Logistik, Einzelhandel und Fertigung. En passant können Roboter Bilder des Lagerbestands oder der Ware in Arbeit erstellen. Mithilfe der Bilderkennung lässt sich beschädigte Ware kennzeichnen.

Zusammenfassung

Autonome Roboter eröffnen eine neue Form der Integration mit betriebswirtschaftlicher Anwendungssoftware, die Software Services für Roboter leicht verfügbar macht. Statt einer Kommunikation über eine Telegrammschnittstelle werden komplexere Auftragsstrukturen zwischen der betriebswirtschaftlichen Anwendung und dem autonomen Roboter ausgetauscht.

Cloud Robotik ist quelloffen, herstellerunabhängig und kann im Gegensatz zu bisherigen Integrationsansätzen in Tagen und Wochen implementiert werden. Weitere Roboter kann der Betreiber ad-hoc hinzufügen. Mithilfe von Kubernetes wird die entsprechende Software automatisch aus der Cloud auf die Roboter installiert und aktuell gehalten. Softwareentwickler, die eigene Dienste für Roboter anbieten wollen, profitieren davon.

Dabei wendet sich die SAP-Entwicklung auch an kleine und mittlere Unternehmen und Organisationen, bei denen Digitalisierung und Automatisierung bisher an prohibitiv hohen Einführungskosten scheiterten. Zu solchen Kosten zählen neben dem meist großen technischen Aufwand auch fehlendes Know-how, weshalb beide Lösungen in erster Linie zur Vereinfachung und Beschleunigung von Automatisierung und Integration beitragen werden.

Cloud Robotik ist ein Beitrag zur Demokratisierung der Robotik, von der Hersteller von Robotern, Softwareentwickler und Betreiber von Robotern profitieren.