Do you want to see our content in English?

x
x

Pay-per-Use-Plattform für Roboter: Wandelbots, SAP und Infineon im Innovationsprozess der „Digital Product Factory“

““

Klicken Sie auf den unteren Button, um den Inhalt von Spotify Player zu laden.

Inhalt laden

IoT Use Case Podcast auf Spotify anhören
IoT Use Case Podcast auf Spotify anhören
IoT Use Case Podcast auf anderen Plattformen anhören

IoT Use Case Podcast #59 - SAP, smart Systems Hub, wandelbots

In dieser Podcastfolge spricht Madeleine Mickeleit mit einem der größten IoT-Hubs in Europa, mit über 450 Partnern im Bereich IoT und KI und in direktem Auftrag des Bundesministeriums für Wirtschaft und Energie arbeitend – Smart Systems Hub. Stellvertretend ist hier Hans Klingstedt zu Gast, Projektleiter für Ko-Innovationsprojekte.

Mit dabei im Podcast sind zwei Partner des Innovationsprojektes Digital Product Factory:

  • Georg Püschel (Mitgründer, Wandelbots)
  • Mathias Kaldenhoff (Partner Sustainability & Innovation Management, SAP)

Zusammenfassung der Podcastfolge

Was machen die Unternehmen, die in dieser Folge ihr Projekt vorstellen? Smart Systems Hub hilft KMUs bei der Integration von IoT-Technologien mit Schwerpunkt auf Prozessoptimierung im Produktionsumfeld. Bei Wandelbots dreht sich alles rund um den intuitiven und vereinfachten Zugang zu Robotern mithilfe von Software. Das Start-Up ist ganz vorn dabei, wenn es um das Thema „No-Code“ für Roboter geht – Programmierung von Robotern ohne einen Programmcode schreiben zu müssen. Mit SAP haben sie den einzigartigen USP diese Daten auch im ERP nutzbar zu machen.

Das vorgestellte Projekt dieses Podcasts ist Teil des Formats „Digital Product Factory“ des Smart Systems Hubs. Hier werden gemeinsam mit Schlüsselpartnern in einer Anbahnungs- und Initialisierungsphase Projektansätze diskutiert – ein sehr großes Netzwerk an Wissen und Know-how.

Diese Folge dreht sich um ein Testbed für die Effizienzsteigerung von Robotern und die Entwicklung eines „Asset-as-a-Service“-Geschäftsmodells auf Basis einer Software-Lösung. Trotz hohem Automatisierungsgrad weisen Roboter häufig noch Potentiale auf – insbesondere in der Interaktion mit Menschen. Wie kann ein Roboter lernen zu verstehen, welchen Arbeitsschritt ein Mensch als nächsten tun möchte? Diese Herausforderung adressierten SAP Deutschland und Halbleiterhersteller Infineon gemeinsam an Smart Systems Hub.

Wie die Lösung und das Ergebnis aussieht und welche (übertragbaren) Mehrwerte es gibt, gibt’s in dieser Podcastfolge zu hören.

Podcast Interview

Hans, magst du dich kurz vorstellen; kurz zu deiner Person und zu eurem Unternehmen, was ihr genau macht?

Hans

Mein Name ist Hans Klingstedt. Ich bin seit anderthalb Jahren beim Smart Systems Hub beschäftigt. Mein Schwerpunkt liegt im IoT-Projekt- und Innovationsmanagement, wo wir unterschiedliche Unternehmen mit ihren Expertisen zusammenbringen und gemeinsam in einer Kooperation Innovationen entstehen lassen. Ich bin Wirtschaftsingenieur, war dann länger bei einem größeren Automobilzulieferer für Softwareimplementierungs-Projekte zuständig, auch für Inhouse Consulting. Und jetzt bin ich sehr glücklich, im Bereich IoT mit unterwegs zu sein.

Für diejenigen, die den Smart Systems Hub noch nicht kennen: Wie du schon sagtest, im Auftrag des BMWi unterstützen wir kleinere und mittelständische Unternehmen bei der Integration von IoT-Technologien, wobei wir hier den Schwerpunkt bei Prozessoptimierung im Produktionsumfeld haben, wo wir sehr stark auf die Zusammenarbeit von Startups, Industrie und KMU setzen und wo wir einen Innovationsfreiraum schaffen, Entwicklerteams stellen, um gemeinsam Challenges und Use Cases zu bearbeiten.


Georg, magst du dich auch kurz vorstellen und was ihr bei Wandelbots genau macht?

Georg

Mein Name ist Georg Püschel. Ich bin Mitgründer von Wandelbots. Bei Wandelbots geht es um den intuitiven Zugang zu Robotern – also die Programmierung, den Betrieb, den ganzen Aufbau von Roboterzellen. Wie man den durch Software einfacher machen kann. Wir haben das Unternehmen vor vier Jahren erst gegründet, wir sind also ein klassisches Risikokapital-Startup, in Dresden. Meine Aufgabe wechselt sehr oft. Momentan kümmere ich mich vor allem um sämtliche Cloud-Themen, also wie man einen Roboter, eine Maschine mit den Cloud-Infrastrukturen von Hyperscalern beispielsweise zusammenbringen kann. Das Hauptprodukt von Wandelbots ist eigentlich ein Tracking-Device, mit einer App dazu. Das Device heißt TracePen, und mit der App kann man die Daten, die man mit dem TracePen sammelt, in einer Roboterzelle automatisch übersetzen auf Roboterbewegungen – das ist dann Teaching. Unsere Kunden sind alle, die jetzt schon Roboter besitzen und die Produktion flexibler machen möchten – wie so ein Stift zum Beispiel, der viel schneller geht. Oder jemand, der noch gar keinen Zugang zu Robotern hat. Für die physische Roboterzelle können wir auf unser Partnernetzwerk zurückgreifen, das aus Systemintegratoren besteht. Wie gesagt, ich gehe jetzt noch einen weiteren Weg in die Cloud – das ist meine Rolle als Experte bei Wandelbots. 


Ihr habt euch wirklich einen richtig spannenden Bereich herausgesucht und auch das Ziel gesetzt, die Programmierung von Robotern radikal zu vereinfachen, ohne überhaupt Programmcode schreiben zu müssen. Finde ich wahnsinnig passend auch zu dem, was wir im Netzwerk tun. Und dieser TracePen, den du angesprochen hast, ist ja so eine Teaching-Funktion von Wandelbots, mit der quasi jeder in der Lage ist, einen Roboter zu programmieren – was natürlich spannend auch für kleine und mittelständische Kunden da draußen ist. Um die Vorstellungsrunde zunächst abzuschließen, Mathias, magst du dich auch kurz vorstellen? SAP kennt man natürlich als großes Softwarehaus, aber ich würde mich freuen, etwas mehr zu dir und auch deinem Fachbereich zu erfahren.

Mathias

Ich, Mathias Kaldenhoff, bin seit 2013 bei der SAP und seit etwa 25 Jahren bereits im Bereich Database und Data Management unterwegs und auch im Bereich Middleware. Ich bin im Partner Innovation Management im CTO-Office in Deutschland und betreue Organisationen, wie Partner, oder Kunden, die Partner werden sollen, oder Organisationen, die überhaupt das erste Mal mit SAP Kontakt haben, in ihren innovativen Lösungen in vier Teilbereichen. Der erste Bereich ist das Shopfloor Management, also immer dort, wo produziert wird. Dazu gehören natürlich auch alle Maschinen, Roboter und Anlagen, die überhaupt produktionsfähig sind, als Asset-as-a-Service-Modell. Heute sehr wichtig, wenn ich über die gesamten Assets rede, ist ein Teilbereich, das Energieeffizienzdaten-Management, was ich dann in verschiedenen Projekten auch tatsächlich mit dem Begriff Sustainability und Klimalösung verbinde. 


Ihr seid jetzt mit SAP Deutschland in dieser Konstellation gemeinsam mit der Firma Infineon sogenannter Challenge-Geber. Hans, dieses Projekt, was ihr heute vorstellt, ist ja eine Challenge, die unter dem Rahmen Digital Product Factory läuft. Kannst du uns hier zu den Hintergründen abholen und dieses Projekt ein bisschen einordnen?

Hans

Smart Systems Hub hat unterschiedliche Formate, so nennen wir das. Eines davon ist die besagte Digital Product Factory, wo wir gemeinsam mit unseren Schlüsselpartnern und deren Partnern – ein sehr großes Netzwerk – in einer Anbahnungs- und Initialisierungsphase Projektansätze diskutieren. In dieser Phase, im Vorfeld des Projektes, haben wir gemeinsam mit SAP und Infineon einen sehr interessanten Überschneidungspunkt gefunden im Umfeld der Robotik. 


Georg, wir haben eben schon von Mathias gehört, es geht um neue Geschäftsmodelle. Du hast ausgeführt, es geht um die intuitiven Zugänge auch zu Robotern, Stichwort Roboter-Teaching, auch um Cloud-Themen. Kannst du uns abholen, was euren Markt und die Kunden aus dieser Industrie bewegt, und vor allem in diesem Kontext der Digitalisierung? Was siehst du für Bewegungen

Georg

In der Industrie, vor allem in der Produktionsindustrie, wo Industrieroboter ja eingesetzt werden – beispielsweise Automobilindustrie, Siliziumindustrie, aber auch ganz viele andere, das sind nur die zwei am höchsten automatisierten –, müssen Roboter digitalisiert werden. Denn der Trend zu Industrie 4.0 kann ja nur erreicht werden – und damit die Senkung der Losgröße und die Flexibilisierung solcher Maschinen –, wenn man die Maschinen intelligenter macht. Dafür braucht es eine Verknüpfung mit Software. Software ist nun mal die Quelle für sämtliche Maschinenintelligenz. Das lässt sich mit so einem einfach-integrierten System nicht lösen. Deswegen ist Digitalisierung und Industrie 4.0 für uns auch die Verbindung zu Cloud und angrenzenden Systemen, die dort arbeiten. Das wollen wir erreichen. Die ganzen Trends von IIoT, Künstliche Intelligenz, Virtuelle Realität, Augmented Reality – die können im Produktionsumfeld dabei helfen, die Arbeit flexibler, leichter zu machen und am Ende, was für alle Automatisierer zählt, die Produktivität zu steigern. 


Ja, flexibler arbeiten und die Produktivität zu steigern, sind hier die Stichworte. Hans, was beobachtest du in euren Projekten am Markt? Was war vielleicht ein Stück weit der Startpunkt, mit SAP und Wandelbots zusammenzuarbeiten?

Hans

Was wir beobachten ist, dass Digitalisierung und auch die Anwendung von IoT eine grundlegende Voraussetzung der Wettbewerbsfähigkeit von speziell auch kleineren und mittelständischen Unternehmen ist. Wir sehen, dass die Komplexität in diesen IoT-Projekten – das kam ja auch schon in mehreren deiner Podcasts zur Sprache – oft hoch ist und dass gerade die Systemlösung Kooperation benötigt, um unterschiedliche Expertisen und Technologien zugänglich zu machen. In diesem Kontext haben wir uns auch in diesem Projekt bewegt. Ich habe eben auch angesprochen, wir haben hier die beiden interessanten Herausforderungen von SAP und Infineon in einem schönen Projekt zusammengelegt. Die waren sozusagen die Challenge-Geber, die Challenge Owner für diese Digital Product Factory. Wir konnten hier dann gemeinsam mit der Firma Wandelbots, Georg Püschel, mit der Software für die Robotik – Georg hat es sehr schön »die Quelle« genannt –, Intelligenz in den Roboter hineinbringen. 


Das war die perfekte Überleitung zu SAP. Mathias, was war euch wichtig zum Start des Projektes? Als Challenge-Geber, was sind die Themen, die euch bewegt haben?

Mathias

Wir müssen die Brücke schlagen zwischen einem rein produzierenden System und den dort verwalteten Daten mit den tatsächlichen Auftragsdaten, mit den Performancedaten und mit den Predictive-Daten. Das heißt, wenn wir irgendwann mal in der Lage sein wollen, zum Beispiel eine Maschine über Daten zu simulieren – das heißt, einen digitalen Zwilling darzustellen, um dann zu sagen, was und wie wird er in den nächsten Zeiteinheiten, kurzfristig produzieren, wie viel Strom braucht er dafür und wo bekomme ich den her? –, dann reden wir nicht mehr nur über die Demokratisierung des Zugangs. Für mich ist Digitalisierung immer eine Demokratisierungsfrage; das war schon immer so. Das Internet hat mehr Leuten Zugriff auf Information gegeben. Und die Digitalisierung einer Maschine, eines Roboters, einer Anlage gibt mehr Leuten Zugriff auf die Maschine und das, was sie tut. Zudem senkt dabei die Eintrittsbarriere. – Wenn ich nun diese Daten dafür benutzen kann, dass ich mein Order Management, mein Forecasting und meine ganze Produktionslinie intelligenter, schonender und besser fahre, dann ist das von hohem Interesse für jede Art von Produktion, jede Art von Order Management und jede Art von Forecast. Das haben wir auch in anderen Projekten schon gezeigt: Wir haben mit einem weiteren Partner, der hier bei der Change stark geholfen hat – objective partner ist der Name –, das Thema Asset-as-a-Service auch dazu genutzt, um tatsächlich Leuten die Beteiligung zu ermöglichen, die sich sonst an solchen Verfahren gar nicht beteiligen können, weil sie die Komplexität nicht beherrschen können, mangels Manpower zum Beispiel – wer hat schon Energiemanager im Bereich des Mittelstandes? 


Georg, was macht ihr seitens Wandelbots bei dieser Challenge genau? Könntest du das Projekt so ein bisschen inhaltlich verorten und uns einen Überblick zu diesen einzelnen Handlungsfeldern geben, die ihr hier habt?

Georg

Da muss man erst mal ein bisschen genauer hinschauen, was denn die verschiedenen Dimensionen oder Aspekte der Challenge waren. Übergeordnet ging es um Unterbrechungsfreiheit. Aber wir haben aus Robotik-Sicht natürlich drei unterschiedliche Sachen gemacht: Das eine ist ein intelligenter Roboter mit einer Art Kamera und einem AI-System, das Entscheidungen des Roboters in seiner eigentlichen Aufgabe direkt manipuliert hat. Dann Predictive Maintenance über SAP-Systeme. Und am Ende das Asset-as-a-Service-Management, also das nutzungsbasierte Beauftragen und Abrechnen des Roboters. Man kann sich das so vorstellen, dass für die Aufgabe, die in die Robotik ging – also mit der AI-Kamera –, wir typischerweise direkt vor Ort das AI-Modell trainiert haben. Also wir haben die Kamera, die einen latenzfreien Zugang zum Roboter braucht, über ein Edge-System – also ein System, das sehr nah an der Maschine steht – trainiert. Das trainierte Modell haben wir dann mit dem Roboter verknüpft, über ein lokales System, sodass direkt in der Zelle die Entscheidungen getroffen werden können. Dieses Datenaufnehmen war eine Aufgabe, in die wir hier viel Zeit in dem Projekt investiert haben. Bei den anderen beiden Bestandteilen geht es vor allem darum, die Daten, die von der Maschine kommen, in die Cloud-Infrastruktur zu transportieren. Das war meine Hauptaufgabe. Da muss jemand da sein, der Cloud-Ingenieur ist und sich mit den verschiedenen Ressourcen und Diensten auskennt, die dort existieren. Denn die Verknüpfung zwischen unserer Infrastruktur, also der Automatisierung, dem Teil, der die Automatisierung versteht, und den Systemen, die auf der anderen Seite wirken – also zum Beispiel SAP Analytics oder der Partner, der Asset Management gemacht hat, nämlich objective partner –, diese Systeme müssen miteinander integriert werden. Aber das ist dann schon wieder klassische Integrationsaufgabe im Softwarebereich. Viel Wert wird auch darauf gelegt, wie man die Daten transportiert. Das ist da die Herausforderung. 


Das heißt, ihr habt erst sozusagen den Roboter selber, der intelligent gemacht wird. Quasi mit dem vor- und nachgelagerten Prozess. Also die Fragestellung, wie kann ein Roboter verstehen, was ein Mensch vielleicht auch als Nächstes machen möchte? Alles rund um diese Mensch-Roboter-Interaktion plus die Software und Intelligenz ist ja dann entsprechend der Part von Wandelbots. Und dann haben wir sozusagen den zweiten Bereich, wo die Challenge darin besteht, die Daten aus anderen Systemen überhaupt verfügbar beziehungsweise nutzbar zu machen, um dann im letzten Schritt wirklich die Möglichkeit zu haben, mit diesen Daten den Roboter auch als neues Geschäftsmodell anzubieten – also auf Basis der Softwarelösung ein Asset-as-a-Service-Geschäftsmodell zu entwickeln. Vielleicht für die, die noch nie von den Themen oder dem neuen Geschäftsmodell in diese Richtung gehört haben: Asset-as-a-Service ist ein Geschäftsmodell, wo man den Roboter nicht mehr als längerfristiges Anlagegut in seiner Bilanz führt, sondern wirklich nur noch nach Nutzung zahlt. Das heißt, ich kaufe den Roboter nicht mehr, sondern zahle nach Nutzung, und das auf Basis von Daten – also der Einsatz des Roboters wird entsprechend kontrolliert, überwacht und abgerechnet. Das bietet verschiedene Vorteile. Hört dazu gerne mal in Folge 4 mit Josef Brunner rein – seine Erklärungen sind immer noch aktuell und sehr charmant. Und in Folge 25 erklärt es noch mal Jonas Schaub von der Firma elunic. Mathias, um noch mal tiefer in die Praxis zu gehen: Was sind hier die Herausforderungen und welche Daten sind für euch interessant? Du hast vorhin von einer Middleware gesprochen. Roboter mit dem neuen Geschäftsmodell umsetzen – wie geht das überhaupt?

Mathias

Unsere Herausforderung war ja die, dass wir die sensorischen Daten plus die Umgebungsdaten, die aus dem Roboter herauskommen, eigentlich interpretieren müssen. Das heißt, wir haben eine Middleware eingesetzt, die kommt vom Fraunhofer-Institut, das ist BaSys, BaSyx – das nennt sich Verwaltungsschale und ist ein Industrie-4.0-, Open-Source-Produkt, mit dem wir dann tatsächlich den digitalen Twin abbilden können. Welche Daten waren für uns wichtig? Um mal einen ersten Schritt zu machen. Nehmen wir mal an, wir haben einen möglichst sicheren Roboter, der in einer sicheren Umgebung als Cobot agieren kann. Dann müssen wir wissen, was ist eigentlich ein Skill? Also was ist ein Arbeitsauftrag und durch welche Bewegung des Roboters bildet der sich ab und wann ist er fertig? Früher hätte man dazu gesagt, ein Start- und ein Stopp-Satz. Dann brauchen wir natürlich Daten, was soll er eigentlich tun? Und dann brauchen wir Daten, in welcher Performanz und Geschwindigkeit, in welchem Wechsel kann er das tun? Und dann nicht nur aufgrund der Interaktion mit einem Menschen, der sich zum Beispiel in der Umfeldüberwachung bewegt. Sondern tatsächlich Performancedaten eines Roboters zu messen, das sind also sensorische Daten, um dann – das haben wir sehr oft – zum Beispiel einen Linienwechsel anzustreben. Das ist das Erste. Das Zweite ist, dass wir Daten brauchen – ich habe ja eben über diese Skills gesprochen. Denn irgendwann müssen wir ja, entweder intern oder auch als Mietmodell extern, die Transaktion, die der Roboter macht, abbrechen – ist ja ein Anlagevermögen. Das hat immer etwas damit zu tun, welche Order er auch bekommt. Und wenn wir es schaffen – das war auch, glaube ich, eine der Herausforderungen, die wir exquisit und gut gelöst haben –, die Order mit einem Skill des Roboters, der vorher antrainiert war, zu verknüpfen und dann auch zu wissen, wann die Order ausgelöst und wann sie beendet wurde, dann können wir alles, was der Roboter tut und für das Order Management beziehungsweise das Shopfloor-System relevant ist, durch die Sensorik messen und auch zählen und von mir aus auch wiegen. Was für die Order wichtig ist, können wir dann machen. Dann haben wir die Verknüpfung zwischen einzelnen Skills und einzelnen Order-Aufträgen. Das heißt, wir können ja theoretisch über die Visualisierung zum Beispiel eines QR-Codes eine Einzelorder an einen einzelnen Skill binden. Das heißt, wir können dem Roboter auch spezielle Aufträge geben und sind damit Segment-of-One-fähig. Das sind alles so relevante Daten. Ich würde sagen, alles, was in der Transaktion passiert. Und wie es passiert und in welcher Performanz es passiert. Das ist relevant für die Order. Alles, was im Bereich von Geschwindigkeit, Stromaufnahme geschieht, ist relevant für die Performanz der Order. Und wenn man diese beiden Sachen zusammennimmt und die quasi über das Asset ausliest beziehungsweise tatsächlich mit Analytics und KI verknüpft, dann ist man auch sehr schnell in der Lage, das sogenannte Forecasting zu machen – auf Strom, Performanz, Linie. Um dann zu sagen, an welchem der beteiligten Roboter führe ich denn jetzt diesen Auftrag aus? 


Ich versuche das mal in eigene Worte zu packen. Das heißt, der Roboter soll zukünftig die Bewegungen von Menschen beispielsweise in der Nähe erkennen und per KI dann entscheiden, ob der Mensch ihm sozusagen näher kommen soll oder nicht – und abhängig davon ändert der Roboter sein Verhalten. Stichwort, Interpretation der Daten oder KI, was wir eben schon angesprochen haben. Und jetzt mit der sogenannten Middleware, also der Verwaltungsschale vom Fraunhofer-Institut, BaSyx, habe ich die Möglichkeit, über eine einheitliche Schnittstelle diese wichtigen angesprochen Daten im Roboter aufzunehmen, um dann diese Prozesse zu visualisieren und eben etwa einen Linienwechsel zu sehen – Stichwort Digital Twin und Daten, genau, wie du es gerade ausgeführt hast. Und dann kann ich on top diese Daten entsprechend nutzen, um das neue Geschäftsmodell für den Roboter zu digitalisieren und die Forecast-Planung und alles, was ich in SAP mache, abzuwickeln. Superspannend. Das sind natürlich auch sehr komplexe Ansätze in diesem Projekt. Verschiedenste Use Case-Technologien, auch Expertisen, die hier auch sortiert werden müssen. Hans, da kommt ihr, glaube ich, aus diesem Innovationsbereich ganz gut ins Spiel. Wie geht ihr das an? Wie geht man so einen Prozess und wie bringt ihr euch hier genau ein

Hans

Es geht los mit dem Zuschneiden des Projektes, indem wir nach den Gesprächen mit den jeweiligen Challenge Ownern die notwendigen Technologien sortieren und dann auch entsprechend in unserem Partnernetzwerk Expertisen suchen und mit einbinden. Das war hier genauso bei Wandelbots der Fall. Als auch dann, dass Mathias zum Beispiel mit objective partner gesprochen hat und wir dann diesen gemeinsamen Case bearbeiten konnten. Das geht dann klassisch über einen Projekt-Steckbrief, wo wir diese Technologien ordnen und dann auch auflisten, welche Ressourcen wir benötigen. Also welche Skills, was wir dann auch international mit Talenten aufgefüllt haben. Wo dann entsprechend sahen, was braucht es für diese Systemlösung? An welchen Stellen benötigen wir solche Expertise, um diese Infrastruktur aufzubauen? So gehen wir dann in der Vorbereitungsphase Stück für Stück vor, um dieses Projektteam abzubilden. Du hast vorhin die Komplexität angesprochen. Tatsächlich, das war zu Beginn eine Herausforderung, wo wir dann auch Teilsegmente gebildet haben, Bearbeitungsblöcke, um insgesamt die 17 Projektmitglieder gut steuern zu können, damit durch uns am Ende natürlich für Mathias aber auch für die Firma Infineon als Challenge Owner minimaler Zeitansatz bei maximaler Mitbestimmung abgebildet werden können – aber zugleich auch die Projektteams gut und effizient arbeiten können. Das ist auch ein großer Mehrwert, den wir mit leisten, dass wir sicherstellen, dass eine gute Koordination der Teams von uns abgebildet wird. 


Wenn ich mir jetzt vorstelle, dass ihr in diesem komplexen Projekt auch mit den ganzen Projektmitgliedern zusammenkommt, um die einzelnen Bereiche anzugehen – sei es das Abrechnungsthema oder den Datentransport –, wie muss man sich vorstellen, wie bringt man das Wissen, die Kompetenzen überhaupt ins Digitale? Ich muss ja sicherstellen, dass die Themen in der Cloud landen, auch strukturiert.

Hans

Lassen wir mal die Data-Acquisition-Termine bei Georg außen vor, wo wir uns regelmäßig getroffen haben, um das AI-Modell zu trainieren – um genügend Daten zu sammeln, um das Modell robust zu bekommen. Von diesem abgesehen haben wir tatsächlich alle Termine digital in einer virtuellen Umgebung abgebildet, wo wir unterschiedliche Tools zur Kommunikation genutzt haben. Da haben wir virtuelle Räume gebildet, wo wir uns zu Bearbeitungszeiten, Bearbeitungsblöcken getroffen und gut aufgeteilt und mit unterschiedlichen Tools gearbeitet haben. Das geht beim Teilen des Bildschirms los, über Kommunikationskanäle wie Slack, über Bitbucket, um Codes zu teilen, bis hin zum gemeinsamen Coding in einer Arbeitsumgebung. Eine richtige Mischung in der virtuellen Umgebung, wo wir uns zu Beginn des Projektes sehr schnell einfinden. 


Georg, wie sieht euer Lösungsbaustein hier genau aus? Ihr seid ja jetzt ein Projektpartner in dem ganzen Konglomerat. Wie funktioniert eure Lösung an der Stelle?

Georg

Man kann sich das so vorstellen, dass Wandelbots sowieso immer bei Industrierobotern ein Edge-Device bereitstellt, was dann mit dem Robotercontroller, also dem Computer, der mit der Maschine kommt, zusammenarbeitet. In diesem Industrie-PC befindet sich unsere Software-Plattform, und die nutzen wir, um die verschiedenen Herausforderungen in dem Projekt zu lösen. Man kann sich das so vorstellen, dass dieser IPC im Prinzip ein Vermittler ist zwischen der On-premises-Welt, also der Produktionsstraße und OT, und der Cloud-Welt. Grundsätzlich werden Dienste implementiert und Software, die die Vermittlung übernehmen zwischen der Maschine, den Datentransport-Einheiten, die bei einem Hypervisor, beispielsweise Microsoft Azure liegen. Und am Ende zusätzlich Dienste, die von dort wiederum in das Zielsystem transportiert werden, beispielsweise SAP. Das heißt, was wir bei Wandelbots getan haben, ist fast nur Software plus ein bisschen einen Roboter zu programmieren, also die klassische Automatisierungsaufgabe zu lösen. Und die Interaktion von allem zusammen löst dann die Herausforderung, die wir uns gestellt haben. 


Mathias, ihr wart der Challenge-Geber, aber habt natürlich auch die Infrastruktur beziehungsweise eure Plattform für dieses Projekt bereitgestellt. Wie funktioniert das auf der SAP-Seite? Wie hat vielleicht auch die Zusammenarbeit in diesem komplexen Projekt funktioniert?

MathiasWir haben zwei große Bereiche der SAP bereitgestellt und in dieses Projekt eingebracht. Das eine ist die Business-Technology-Plattform, also die Cloud der SAP, die Extension unseres Intelligent Enterprise, SAP S/4HANA ist der Nachfolger von SAP R/3. Und wir haben ein angeschlossenes S/4-System, in dem wir unsere Orders verwaltet haben. Und in dem wir auch tatsächlich – und das ist, glaube ich, etwas ganz Neues; das habe ich zumindest am Markt noch nicht gesehen – die Credits verwaltet haben. Das heißt, wir haben ein internes Abbuchungssystem bereitgestellt, in dem wir die Transaktionen bereits mit Credits belegt und abgerechnet haben. Und noch etwas haben wir getan. Ich würde sagen, Hans, das ist eigentlich ein Schutzraum, weil wir hier wirklich unter einem Dach zusammenarbeiten konnten – das hat man ja sonst nicht, weil wir wirklich interdisziplinär sind: Wir haben den Anteil von BaSys und BaSyx, also den Verwaltungsschalen beziehungsweise den Anteil Digital Twin, auf der Business-Technology-Plattform ausgebracht und mit der IoT-Edge von Azure so miteinander verbunden, dass wir ein Gesamtsystem erstellen konnten. Und zwar kollaborativ, und nicht kompetitiv – das ist mir ganz wichtig gewesen. So haben wir eine durchgängige – das ist der Dank, der dem Smart Systems Hub gilt – Datenstrecke gehabt, vom Roboter, seinen sensorischen Daten, den Umfelddaten, bis hin tatsächlich zu den Auftragsdaten und Abrechnungsdaten. Und das war EINE Sicht. Ich glaube, das ist das, was hier wirklich hervorzuheben ist. Denn wenn man sich die einzelnen Expertisen anschaut und würde die spezialisieren, dann wäre der ein oder andere gar nicht mehr in der Lage, einzeln ein solches Gesamtsystem zu machen. 


Hans, wie sieht denn zusammenfassend der Business Case aus? Ihr habt ja in der Konstellation mit den einzelnen Projektmitgliedern ein ganzheitliches System entwickelt, die gesamte Expertise zusammengebracht. Wie funktioniert das mit dem Business Case für dieses Projekt?

Hans

Stellen wir uns ein Unternehmen vor, was produziert – ein bestimmtes Material. Und wir haben hier eine Lösung, die wir bereitstellen, die einen Prozess automatisieren kann. Der mit menschlicher Interaktion optimiert wird – also das kein Robotisierungsfall ist, kein reiner Robotikfall, sondern wo die Interaktion zwischen Mensch und Roboter optimiert wird. Das heißt, weniger Stillstandszeiten für Robotik. Und zum anderen, für das Unternehmen selbst, was Materialien produziert, kann der Roboter allein auf Basis dessen, was er tatsächlich tut, abgerechnet werden. Das bewirkt die Reduzierung von Investitionskosten und somit eine geringere Eintrittsbarriere hin der Nutzung von Robotik und der Automatisierung für dieses Unternehmen. 


Mathias, wie sieht der Business Case für euch aus?

Mathias

Hans hat ja viel davon schon gesagt. Wir sind in der Lage, jetzt Marktplätze für digitale Services unseren Kunden zu liefern, die wiederum den Nutzern digitale Services mit der Hardware zusammen liefern wollen. Das ist der erste Punkt. Wir sind in der Lage das abzurechnen. Und wir sind in der Lage, den Lieferanten einen entscheidenden Vorteil für den Markt zu liefern: Nämlich höhere Verfügbarkeit seiner Leistung, weil er über die Predictive-Maintenance-Anteile – die wir jetzt noch nicht ganz so stark angesprochen haben –auch in der Lage ist, das ganze Thema Maintenance, also Support, transaktionsorientiert zu bepreisen. Das ist der erste Business Case. Der zweite Business Case ist, dass wir Shopfloor-Management-Systeme auch für kleinere und mittlere Unternehmen verfügbar machen. Das heißt, ihnen neue Technologien bereitstellen können. Das war der Demokratisierungsansatz. Und wenn ich über die Marktplätze spreche, dann wollte ich auch noch ein bisschen auf das Thema Security eingehen, speziell in der Robotik. Ich bin kein ausgewiesener Roboter-Spezialist, aber ich habe mich jetzt mit vielen Roboter-Herstellern unterhalten. Deren größtes Problem ist, dass sie Angst haben, dass ihr Roboter und das, was er kann, kopiert wird. Sprich, würde ich mal sagen, so, wie es ein iOS gibt für ein Apple iPhone, so gibt es ja auch ein Robotik-System, in dem wahrscheinlich Artificial Intelligence steckt, wie sie ihre sieben Arme bewegen, wie sie sensorisch messen, was sie daraus für Experiences haben und so fort. Und was sie auch immer mitliefern, auch in fremde Länder, ist ja das, was der Roboter tut. Also das Zählen und die Performanz und wie der Auftrag aussieht – dass ich das dann direkt beim Roboter abfassen könnte. Ich könnte ihn hacken. Was wir jetzt erreicht haben – das ist, glaube ich, etwas, das man nicht hoch genug bewerten kann –, ist, dass wir in der Lage sind, mit Wandelbots und dem ganzen Team, was wir hier geschaffen haben, das eigentliche Robotik-System von seinen Skills zu trennen. Also die Skills könnten zum Beispiel in irgendeinem Intelligent Enterprise oder in der Cloud veräußerbar laufen und dort gebucht werden – das heißt, ich erhalte ein Stückchen Hardware, das ist wie mein iPhone … ich bin aber ohne den App Store eine Wurst. Also ich habe ein Betriebssystem im iPhone, aber das eigentlich Entscheidende ist das Ökosystem App Store, wo ich dann tatsächlich die Dienstleistung, die diese Hardware vollführen kann, kaufen muss, mieten kann oder was auch immer. Und das in ein Subskribierungsmodell zu bringen, das ist auch unser Business Case. Also der ist schon relativ komplex und den führen wir jetzt auch – was für mich die Zukunft ist – sowohl mit dem Smart Systems Hub als auch mit einigen Robotermaschinen-Herstellern durch. Denn was für einen Roboter klappt, klappt natürlich auch zum Beispiel für eine Wallbox. 


Hans, ihr seid jetzt mit verschiedensten Use Cases und Projekten unterwegs. Wie lässt sich dieser Use Case beziehungsweise dieses Projekt übertragen? Gibt es die Möglichkeit, diese Projektart auch auf andere Use Cases zu übertragen oder ist das ein individueller Fall, den ihr jetzt in diesem Expertenkreis für produzierende Betriebe gelöst habt?

Hans

Mathias hat da auch einen guten Hinweis gegeben: Ob das jetzt ein Roboter ist oder ein anders Asset, steht erst mal frei. Das heißt, auch jegliche andere Maschine, jegliches anderes Asset kann in diesem Testbed, das wir letztendlich entwickelt haben, so in einem neuen Geschäftsmodell, in einem Pay-per-Use-Modell, zur Verfügung gestellt werden. Das bedeutet, diese Infrastruktur, die wir aufgebaut haben, können wir gut übertragen in andere Implementierungsszenarien. Das ist natürlich ein sehr schönes Testbed, was man jetzt anwenden kann, wo wir mit anderen Partnern, anderen Unternehmen, die Anwender sein können, das entsprechend ausrollen können. Das ist der eine Aspekt, dieser beschriebene Nutzen der vorhandenen Leistungen, was wir aus diesem Projekt herausgenommen haben. Das Zweite ist natürlich, wir hatten viele Learnings in dieser Struktur, und natürlich haben wir in dieser Projektart, Digital Product Factory, eine Methodik entwickelt, die wir in diesem Projekt auch wieder gut unter Beweis gestellt haben, wo wir auch neue Use Cases bearbeiten können. Wo wir so ein Szenario abbilden können … was allerdings zu einem neuen Innovationsthema führen würde. 


Georg, ihr seid jetzt auch in zwei Hauptkompetenzen unterwegs, neben dem Roboter-Thema auch die Software. Wie lässt sich dieser Use Case auf andere Kunden übertragen? Oder ist das für euch ein individueller Case?

Georg

Das Wichtigste bei Wandelbots ist vor allem, dass wir immer bei Robotern bleiben. Das ist unsere Kernsicht; wir beschäftigen uns immer mit Industrierobotern. Das könnten natürlich grundsätzlich auch andere Roboter sein, zum Beispiel Fahrroboter; am Ende geht es aber um Robotik. Was wir jetzt im Projekt gelernt haben, ist letztendlich, wie wir Cloud-Systeme auch von dritten Parteien zum Roboter hinbringen, wie das geht, was dabei für Probleme auftreten und was für Geschäftsfelder rings um unseren Roboter vielleicht noch lauern, die wir auch nutzen könnten, um neue zukünftige Produkte zu bauen. Aber grundsätzlich muss man sagen, vom Roboter aus gedacht kann man auch sämtliche andere Ideen, die irgendetwas in der Cloud beispielsweise stattfinden lassen, mit dem Roboter verknüpfen – etwa AI-Systeme, die Entscheidungen für den Roboter treffen aufgrund von Daten, die im Internet vorhanden sind. Oder die AI-Dienste auf Hyperscalern benutzen. Oder man verbindet den Roboter mit einem Logistik-System. Solche und ähnliche Sachen könnte man machen. Oder man teilt Wissen zwischen verschiedenen Kunden über die Cloud. All diese Ideen und Ansätze lassen sich über eine ähnliche technologische Grundlage verwirklichen. Das ist, denke ich, auch ein Outcome des Projekts, dass man solche Dinge auf eine ähnliche Art und Weise tun kann. 


Es birgt auf jeden Fall einiges an Potenzial. Mathias, ist das für euch ein Use Case, der übertragbar ist?

Mathias

Der ist übertragbar. Ich übertrage ihn übrigens auch schon. Es gibt zwei Dinge, die ich übertrage. Das Erste ist, was Hans angesprochen hat: So ein interdisziplinäres Testbed ist Gold wert. Das ist erst mal total wichtig, denn wann findet man schon die Gelegenheit, in einem Schutzraum mit einer Maschine zu kommunizieren? Und auch noch mit, ich würde sagen, dem höchsten Diversifizierungsgrad – das ist nämlich ein Roboter. Bei allem anderen, wenn es ums Stanzen geht oder Bohren oder Hobeln, ja, da müssen wir auch über Präzision reden. Aber einen Sieben-Achs-Roboter zu vermessen und da die Daten richtig zu interpretieren, »Wann ist das eigentlich ein Auftrag?«, das ist schon hohe Kunst. Also das Testbed ist für uns sehr wichtig und das werden wir weiter stützen und gern weiter nutzen wollen. Nutzen sage ich in positivem Sinne. Aber was wir gelernt haben, übertragen wir jetzt auf viele Zugänge im Bereich unserer Kunden in den Bereichen Shopfloor und überhaupt Servisisation, wie das so schön heißt im IoT-Umfeld. Und haben natürlich dadurch auch, denke ich mal, über diesen MVP – das ist ja kein Showcase mehr – eine sehr, sehr gute Referenz, wo wir auch zeigen können, dass das geht. All die Dinge, die ich genannt habe, das sind ja alles Benefit-Diskussionen: Warum lohnt es sich für einen Mittelständler, über Digitalisierung nachzudenken, wenn er über Roboter spricht? Oder warum lohnt es sich, einen Roboter einzusetzen? – Weil wir es jetzt tatsächlich geschafft haben, die Eintrittsbarriere plus alle Schutzbestimmungen, Umfeldüberwachung und so weiter zu senken. Und weil wir in der Lage sind – und das ist, glaube ich, das Wichtigste für die SAP –, CapEx to OpEx zu machen. Das heißt, kapitalintensive Kosten, ich kaufe mir einen Roboter. Nächste Stufe war, ich lease mir einen Roboter. Und jetzt miete ich mir einen. Und das können wir speziell in Deutschland sehr oft und mit sehr vielen Kunden machen. Sei das in Pumpen. Sei das in der Agrarwirtschaft, wo wir viele Pumpen haben. Wo so etwas tatsächlich wichtig wird. Wo wir eigentlich auch eine Art von Robotik haben – jede Melkmaschine ist eigentlich ein Roboter für mich. Und jede Pumpe, Zentrifuge, die das tut, auch. Das heißt, wir können hier viel, viel, viel Gutes bewirken und einen Innovationsstoß für den Mittelstand in Deutschland bewirken. Das ist, glaube ich, für die SAP sehr wichtig. 


Mathias, wenn ich jetzt produzierender Betrieb bin und genau an diesen Themen gerade arbeite und gerade zuhöre – wann muss ich mich an euch wenden? Geht es dann um die Gesamt-Challenge? Oder wann seid ihr der perfekte Ansprechpartner?

Mathias

Immer dann, wenn ich über Produktion rede. Materialplanung plus Performanz. Und irgendwann muss ich eine Rechnung schreiben. Das klingt jetzt zwar sehr banal, aber das ist für die meisten Unternehmen so … wenn sie keine Rechnungen schreiben, gehen sie pleite. Das heißt, also alle Daten von Performanz –alles, wo wir über Technik geredet haben – muss sich irgendwann in einer Rechnung widerspiegeln. Sei es vom Nutzer oder sei es vom Lieferanten. Immer dann, wenn es tatsächlich in die Finanzbuchhaltung geht. Selbst ein Grünstrom-Datensatz – darüber reden wir ja auch –, der muss auch irgendwann in die Finanzbuchhaltung; und sei es wegen der CO2-Steuer. Also immer dann, wenn wir entweder über Financial Management oder über Produktion, also Manufacturing reden, kann man sich an uns wenden. Dann, glaube ich, sind wir ein guter Mittler. 


Hans, ihr seid wahrscheinlich der Ansprechpartner für alles rund um die MVP-Entwicklung, oder den Prozess, um überhaupt so einen Weg zu gehen?

Hans

Genau. Um das auch noch mal bildlich darzustellen: Wir verfügen über unterschiedliche Technologien, die von der Hardware über die Roboter-Programmierung über die ganzen Cloud-Services bis hin zu der Verwaltungsschale, dem Asset-as-a-Service, gehen. Diese unterschiedlichen Technologien haben wir mit dem Partner zusammen bearbeitet und können nun dieses Testbed, das wir entwickelt haben, neuen Unternehmen zur Verfügung stellen, damit sie selbst neue Geschäftsmodelle entwickeln. Genau in diesem Umfeld bewegen wir uns, wo wir sehen: Wir verbinden unterschiedliche Technologien miteinander, wir nutzen KI, neue Modelle, neue Möglichkeiten, um neue Zugänge zu schaffen. Genau in diesem Umfeld bewegen wir uns, mit dieser Art von Projekten. Das andere Thema ist, was Mathias angesprochen hat, dies zugänglich zu machen für Maschinenhersteller, für Robotik-Hersteller – all diese Unternehmen, die Assets vielleicht in neuen Geschäftsmodellen zur Verfügung stellen möchten. 


Mathias, du hast es auch schon gesagt; aber um noch mal den Kreis zu schließen: Für euch sind eigentlich alle Anwendungsfelder interessant im produzierenden Betriebe, die solche Roboter zum Einsatz bringen oder neue Roboter anschaffen wollen – oder wann seid ihr der perfekte Ansprechpartner?

Mathias

Überall dort, wenn wir eine Anlage installiert bekommen, in die tatsächlichen Produktionsprozesse oder in die Lieferprozesse. Das hört ja nicht auf bei den stationären Robotern. Sondern was wir daraus machen, ist, dass wir das Ganze auch in der sogenannten Digitalen Lieferkette, also Digital Supply Chain, verorten wollen. Da ist es dann dementsprechend kein Roboter, sondern zum Beispiel ein Lastenträger, der an verschiedenen Punkten vorbeikommt. Man merkt schon, immer dann, wenn es um Produktion und ein Asset geht, das irgendeine Leistung jetzt digitalisiert darstellen kann, dann sind wir eigentlich der Ansprechpartner – spätestens dann, wenn wir in den Produktionsprozess eingreifen wollen … wenn wir das in Sales und Marketing bringen wollen … wenn wir das in den Finanzsatz bringen wollen. Also alle diese Dinge, die dazugehören. 


Georg, ihr seid dann der Ansprechpartner für alles rund um Robotik und Software, richtig?

Georg

Ganz genau. Bei uns geht es um Roboter, und wir versuchen, die Roboter intelligenter zu machen – die Programmierung, den Betrieb, die Überwachung, die Steuerung des Roboters. Da gibt es natürlich sehr viele Anwendungsfelder ringsum. Wir können nicht alles gleichzeitig machen, aber unsere Vision ist es, eine Plattform zu bauen, auf der man diese ganzen Anwendungen mit Partnern zusammen vereinfachen kann. Deswegen interessiert uns ALLES, was mit Robotern zu tun hat. Wenn jetzt aus dem Projekt heraus oder aus den angrenzenden Geschäftsfeldern für uns ein neues Geschäft entsteht und da ein großer Partner wäre, das wäre für uns auf jeden Fall ein Highlight. Dann wüssten wir auch, dass wir dort besonders viel Augenmerk vielleicht für zukünftige Produkte darauf legen können, die wir auf Grundlage unserer Plattform bauen.

Für Rückfragen stehe ich Ihnen gern zur Verfügung.

Questions? Contact Madeleine Mickeleit

Ing. Madeleine Mickeleit

Host & Geschäftsführerin
IoT Use Case Podcast