Zusammenfassung der Podcastfolge
Folge 65 auf einen Blick (und Klick):
- [07:33] Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus
- [14:10] Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien
- [27:26] Ergebnisse, Geschäftsmodelle und Best Practices – So wird der Erfolg gemessen
- [32:18] Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen
Wir stellen eine Neuheit im Bereich IIoT in der Robotik vor. Jeder kennt sie vermutlich: die orangefarbenen KUKA-Roboter in jeder Anwendung, Form und Größe. Nun geht KUKA den Weg, die Daten in Echtzeit über ihre neue IIoT-Plattform KUKA iiQoT nutzbar zu machen. Diese Plattform ist für alle Roboter-Flotten – egal, ob ich fünf davon habe, hundert oder tausende. In dieser Podcastfolge geht es darum, welche Mehrwerte die neue Lösung für einzelne Use Cases genau mit sich bringt. Wir sprechen darüber, wie man die Betriebszeiten der Roboter-Flotten auf ein neues Level bringt. Mit dabei ist der IoT-Experte Device Insight.
Was bedeutet iiQoT? ii = industrial intelligence, iQ = intelligentes Leistungsvermögen und IIoT altbekannt für das Industrial Internet of Things
Podcast Interview
Thomas, du bist CTO und Managing Director bei der Device Insight. Ihr seid Tochter der KUKA und quasi als IoT-Spezialist unterwegs, baut IoT-Lösungen, connected Products, seid Microsoft-Azure-Gold-Partner und vieles mehr. Kann man das so sagen?
Thomas
Gut zusammengefasst. Wir bei Device Insight beschäftigen uns seit unserer Gründung im Jahr 2003 mit dem Thema IoT, auch wenn es den Begriff damals noch nicht gab. Im Grunde hatten wir schon immer die Vision, Maschinen, Anlagen und Geräte zu vernetzen und darauf Applikationen aufzubauen. Wir machen das in ganz verschiedenen Branchen. Das heißt, wir helfen unseren Kunden dabei, Industrial-IoT-Lösungen umzusetzen, und ich bin als CTO in erster Linie verantwortlich für die Software-Entwicklung – das heißt sowohl die Entwicklung eigener Produkte und Komponenten, aber auch Systemintegration, welche wir für Kunden durchführen, um komplette End-to-End-Lösungen aufzubauen.
Auch waren wir vor einigen Jahren für die KUKA tätig. Daraus ist dann etwas mehr geworden: Wir sind eine Tochter der KUKA und unterstützen die KUKA-Kollegen bei IoT-Vorhaben. Da ist das Spannende, dass wir diese Kompetenz aus dem Bereich Shop Floor und Automatisierung von der KUKA und unsere Kompetenz im Bereich Cloud und IoT zusammenbringen.
Richard, ein herzliches Hallo in deine Richtung. Du bist heute dabei als Senior Vice President R&D Platform Applications & Tools der KUKA-Deutschland GmbH. KUKA kennt man natürlich als weltweit führenden Anbieter intelligenter Automatisierungslösungen. Ihr baut Roboter von der Zelle bis hin zur vollautomatisierten Anlage, mit einem Umsatz von ca. 2,6 Milliarden Euro, 14.000 Mitarbeitern und Hauptsitz in Augsburg. R&D Platform Applications & Tools: Kannst du mal erklären, womit genau du dich beschäftigst – geht es da um die strategische Entwicklung der Plattform?
Richard
Ja, ich beschäftige mich auch mit der strategischen Entwicklung unserer IoT-Plattform. Ich freue mich schon, im weiteren Verlauf darüber zu sprechen. Allerdings steht dieser sperrige Begriff Applications & Tools auch für vieles mehr in unserem Portfolio. Einmal geht es bei mir um die Tools in der R&D; wir arbeiten an Software-Lösungen, die die Konfiguration, die Programmierung unserer Roboter möglichst leicht machen. Ein ganz wichtiges Thema ist die Simulation, also auch die virtuelle Welt für die Automatisierung, wodurch es noch mal leichter wird, Anlagen, die man nicht schon bei sich auf dem Shop Floor stehen hat, in Betrieb zu nehmen. Und die Applications, die der Roboter am Ende ausführen soll – der Roboter ist ja kein Selbstzweck. Wir wollen Schweißen, Palettieren, Kleben und Montieren – darum geht es bei mir: um die Software-Entwicklung für genau diesen Unternehmensbereich.
Mal ganz zu Beginn, was ist denn eure Vision in diese Richtung? Du sprichst von Applications, von Tools – wo wollt ihr hin mit KUKA?
Richard
Die Mission für 2030 ist, die Einstiegsschwelle für die Automatisierung zu senken. Wir wollen diese für jedermann verfügbar und auch erlebbar machen. Unser CEO, Peter Mohnen, drückt das so aus, dass Automatisierung so einfach werden soll wie die Arbeit am PC. Das heißt, der heutige Zustand ist mehr eine Spielwiese für Ingenieure und Techniker – und diese Spielwiese von sehr gut ausgebildeten, wenigen Leuten soll so einfach werden, dass sie überall anwendbar und realisierbar ist. Dazu entwickeln wir Simulations- und auch Anwendungssoftware, die ein einfaches Setup möglich machen, eine einfache Programmierung, Konfiguration, auch das Zusammenbinden mit anderer Peripherie, wie Sensor, Kamera oder Schweiß-Timern und Greifern. Also alles was eben nötig ist, um die Roboter-Applikation zu realisieren. Damit das möglichst einfach wird, gibt es für uns natürlich viel zu tun, viel zu entwickeln. Aber es macht auch tierisch Spaß, diese Smart Automation greifbar zu machen.
Da gibt es auch verschiedenste neue Features und Möglichkeiten, die eure IIoT-Plattform mit sich bringt. Thomas, wir sprechen hier über Use Cases aus der Praxis, um die Technologien dahinter einfach und verständlich zu erklären – was habt ihr uns heute mitgebracht und welches Projekt schauen wir uns im Detail an
Thomas
Es waren in der Vergangenheit schon Kollegen von mir bei dir, die verschiedene Sachen von Device Insight vorgestellt haben. Da haben wir zusammen mit RAFI eine leichtgewichtige Shop-Floor-Digitalisierungslösung und aus einer ganz anderen Branche auch schon mal Kaffeeverkaufsautomaten betrachtet. Heute geht es um das Produkt iiQoT von KUKA – kurz gesagt, eine sichere und skalierbare IoT-Plattform für die KUKA-Roboter. Die Gemeinsamkeit aus unserer Sicht ist der Begriff »Connected Products«, was die Möglichkeit darstellt, dass Hersteller nicht nur ihre angestammten Produkte verkaufen, sondern auch das Anreichern um digitale Lösungen außenherum. Mittlerweile kennt man ja zum Beispiel das Connected Car, die Connected Waschmaschine bis hin zur Zahnbürste – aber in der Industrie sieht das natürlich etwas anders aus, weshalb Richard heute dabei ist.
Richard
Genau; ich erkläre mal, wie das bei den meisten unserer Kunden aussieht. Wir finden in der Industrie einen ganz interessanten Zustand vor: die sogenannte OT-Welt ist nicht vernetzt mit dem Internet. Das heißt, untereinander auf dem Shop Floor sind die Geräte sehr wohl vernetzt. Jedoch gibt es kein Tor nach draußen, also nicht die Möglichkeit, zum Beispiel Software-Updates over the air zu realisieren, wie das heute sonst total üblich ist, oder auch von außen auf die Geräte zuzugreifen. Typischerweise ist die OT-Welt gut vernetzt, aber eben nicht mit Draußen. Das heißt, wir machen es zum Beispiel so, dass wir uns beim Ausliefern von Updates auf ein sogenanntes Sneakernet statt auf das Internet verlassen. Dort gehen wir wirklich mit Servicetechnikern, in Turnschuhen, deswegen Sneaker, und USB-Sticks los, um Upgrades zu verteilen. – Das ist natürlich nicht zeitgemäß, was wir und unsere Kunden ändern wollen. Das ist der Kern, warum wir mit Device Insight an dieser IoT-Plattform arbeiten; um all die Dinge möglich zu machen, die durch vernetzte Produkte und vernetzte Roboter möglich werden.
Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus [07:33]
Du hast gesagt, es geht unter anderem darum, von außen auf die Roboter zuzugreifen oder nach außen die Daten zu senden, welche für verschiedene Gewerke auch gewinnbringend sind. Was genau sind denn die Herausforderungen eurer Kunden im Alltag beziehungsweise auch Potentiale, die ihr seht? Die man heben kann, weg von der OT-Welt, die ja schon vernetzt ist, sondern hin nach außen?
Thomas
Wir haben heute vor allem die Herausforderung, dass unglaublich viel zu Fuß stattfinden muss. Der Kunde hat keinen kompakten Überblick über seine Roboter-Flotte, kennt die Zustände der einzelnen Automatisierungslösungen mit den Robotern nicht und kann Betriebsparameter nicht einsehen.
Wir haben heute Lösungen wie das smartPAD, also unsere Bediengeräte, wirklich am Zaun außen beim Roboter hängen, welche ständig den Programmablauf und weitere Informationen anzeigen. Das heißt, wenn jemand im Fehler- oder Überwachungsfall sehen möchte, wie gut es in der Linie läuft – quasi einen Herzschlag der Linie spüren –, muss er vor Ort hingehen und es sich anschauen. Dies ist nicht zeitgemäß und das wollen wir mit der IoT-Plattform verändern, sodass man von außen, remote, zentral zugreifen kann. Mit dem Fernzugriff wird ein persönliches Erscheinen nicht mehr nötig sein, um zu reagieren oder Daten und Informationen aufzunehmen.
Geht es da auch um die Inbetriebnahme? Wenn so ein Roboter ausgeliefert wird, dass man den schon bei der Auslieferung in Betrieb nehmen kann?
Richard
Genau, es gibt einen deutlichen Schub in Richtung Einfaches Setup. Wir haben vorkonfigurierte Files, die von der Produktion aus beim Kunden zu einem Unboxing-Event werden und ein leichtes Inbetriebnehmen möglich machen; nur noch nicht den direkten Remote-Zugriff. Es gibt die Möglichkeit, sich relativ schnell anzumelden; aber man ist schon vor Ort und muss Kabel stecken. Dieser Schritt ist noch ein ganz normaler Schritt, wie beim Auspacken der eigenen Geräte; Auspacken, Anstecken, Aufladen, wie beim Smartphone. Danach ist der Remote-Zugriff relativ schnell möglich. Wir haben heute vorinstallierte Systeme; das sogenannte KDC, KUKA.DeviceConnector, ist vorinstalliert, sodass das Tor zur vernetzten Welt möglich wäre – und wenn dann ein Kunde auch das IoT-Produkt von uns nutzt, hat er von vornherein die Möglichkeit, auf die von uns gelieferten Funktionen zuzugreifen.
Thomas, es geht um Zustände, Betriebsparameter und so weiter – hast du einen Einblick, welche Daten für euch und für KUKA besonders spannend sind, die ihr nutzen wollt, um die Lösung darauf aufzubauen?
Thomas
Es gibt erst mal verschiedene Kategorien von Daten. Man teilt sie ein zum Beispiel nach der Frequenz, in der man sie überträgt. Eine Software-Version ändert sich ja nicht alle paar Minuten, sondern eben nur, wenn man sie aktualisiert. Dann noch Betriebsparameter; eine CPU-Auslastung der Steuerung oder eine Speicherauslastung – die sind ja deutlich hochfrequenter. Das sind alles Zustandsdaten, die regelmäßig übertragen werden. Das ist wichtig etwa für das Asset Management – also um zu wissen, welche Software-Stände habe ich zum Beispiel in meiner Flotte? Auch Überblicksfunktionen – wie viele Roboter welchen Typs habe ich? Da sind natürlich diese Daten sehr zentral. Aber auch Features wie Condition Monitoring – wenn ich zum Beispiel benachrichtigt werden möchte, wenn ein Roboter dauerhaft auf einer hohen CPU-Auslastung läuft. Eine andere Kategorie sind Ereignisgetriebene Daten, wo man Meldungen erfasst, die in der Robotersteuerung auftauchen. Klassischerweise sind das Fehler- und Warnungsmeldungen, aber auch Dinge wie Change Logs. Also Dinge zum Beispiel, die vor Ort geändert werden, welche man dann zentral erfassen und so eine zentrale Nachverfolgung ermöglichen kann. So sieht man, ob irgendwo unerwartet Dinge geändert wurden, die man so noch nicht möchte.
Du hast gesagt, zum Beispiel CPU-Auslastung, heißt, dass der Roboter an einer Leistungsgrenze läuft, die irgendwann nicht mehr gesund ist? Kann man sich das so vorstellen, dass man sagt, da muss man genauer hinsehen, da es sonst zu Stillständen kommt?
Thomas
Genau; das sollte nicht der Fall sein, aber das sind genau die Dinge, die man erkennen möchte: Dass der Roboter nicht mehr so arbeitet, wie er soll.
Richard
Das kann die Rechenkapazität sein, die wir in der Steuerung oder in weiteren Rechnern, Box-beside-the-Box-mäßig, bereitstellen. Aber auch Motorströme und Ähnliches sind sehr interessante Parameter, welche man gerne einsehen möchte. So stellt man sicher, dass der Health State, der Gesundheitszustand des Systems überwacht ist. Wir wollen die Flotte optimieren; dass die Roboter auf dem neuesten Software-Stand sind. Wollen die Fehlersuche effizient gestalten, die Betriebszeit maximieren, eine klare und schnelle Übersicht für den Kunden und auch für uns sowie die für die Wartung zuständigen Experten ermöglichen.
Wenn ich in das System eintauche – es geht um die Plattform iiQoT –, was sind Anforderungen? Ihr habt ja bei Device Insight eine Plattform aufgebaut.
Richard
Zunächst war uns wichtig, dass man klar auf den kompakten Überblick der Daten kommt. Wir bieten unglaublich viele Variablen an. Ich habe gerade schon den KDC genannt, der die Variablen abrufbar macht. Wir wollen dann als erste Anforderung natürlich sicherstellen, dass das sicher passiert. Die Daten sollen verfügbar, sicher übertragbar – wir reden ja von einer Cloudanwendung – und leicht konsumierbar für die Zielgruppe sein. Auch ist wichtig, dass die Plattform skaliert – denn es geht ja nicht immer nur um einen Roboter, sondern auch mal um eine Roboter-Flotte. Es gibt einige wenige Kunden, die haben viele tausend Roboter. Wir verkaufen gut und gerne 40.000 Roboter pro Jahr. Das heißt, die Installed Base ist entsprechend groß. Aber es gibt auch einige Kunden mit nur wenigen Robotern. Je nachdem, wen wir aufschalten wollen, muss sich die Plattform an die Bedürfnisse des Kunden anpassen können. Wichtig ist uns auch, dass wir auch in der gesamten Roboteranzahl gut skalieren.
Genau, also Skalierbarkeit heißt im Endeffekt, dass ihr auf eine Technologie setzt, die ausbaubar und anpassbar ist an die unterschiedlichsten Kunden.
Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien [14:10]
Dann lasst uns in die Lösungen eintauchen und in die Plattform, wie sie genau funktioniert. Ihr habt die KUKA iiQoT-Plattform gebaut – das ist eure eigene IIoT-Plattform für die Roboter-Flotten, egal ob 5 oder 200 Roboter. Es geht darum, die Fehlersuche und -behebung zu realisieren, die Flotte zu optimieren und eine schnelle, effiziente Übersicht über die Roboter zu schaffen.
Ihr habt gesagt, es geht auch um einen sogenannten Connector, der schon installiert ist. Hangeln wir uns von der Datenaufnahme, Hardware, über die Verarbeitung bis zur Auswertung – Thomas, wie funktioniert die Datenaufnahme aus den Robotern?
Thomas
Wir starten da nicht bei Null, sondern es gibt schon ein Software-Modul für die Robotersteuerung namens KUKA.DeviceConnector, KDC. Dieser stellt die Daten zur Verfügung, auf eine standardisierte Art und Weise, zumindest was die Protokolle betrifft – OPC UA. Das ermöglicht auch ein Pub/Sub, also das Publizieren der Daten, aktiv, zum Beispiel über MQTT, sodass wir nicht proprietäre oder seltsame Lösungen bauen müssen. Sondern wir können uns an Best Practices halten, die in der Industrie auch an allen Stellen üblich sind. Das ist der Startpunkt.
Der nächste Schritt, um die Daten an die iiQoT-Plattform weiterzuleiten, ist ein Modul, was wir Cloud Connector nennen, da der Roboter nicht direkt in die Cloud schickt, sondern an eine Zwischenschicht. Das hat mehrere Gründe. Auf der einen Seite ist es noch mal eine Sicherheitsschicht. Man möchte in der Regel den Roboter nicht direkt ans Internet hängen. Der Cloud Connector kann hier die aktive OPC-UA-Schnittstelle nutzen, um beispielsweise Funktionen auszuführen. Er ist auch die Schicht, die dann letztlich an der Cloud-Plattform authentifiziert. Hier können wir fertige Komponenten und Services nutzen, die uns ein Cloudprovider zur Verfügung stellt. Also alles, was mit Zertifikaten, Updatefähigkeit, Authentifizierung zu tun hat, müssen wir nicht selber bauen. Sondern da nutzen wir Dinge, die es schon gibt.
Perspektivisch könnte dieser Cloud Connector auch mehr Funktionen übernehmen, wie die Vorverarbeitung von Daten. So müsste man nicht alles an die Plattform schicken, sondern hat voraggregierte Daten. Das wäre der Ort, an dem man das auch geschickt erledigen könnte. Heute ist das noch nicht der Fall.
Okay, es kann ja auch sein, dass Kunden schon selbst Daten vorverarbeitet haben, die man vielleicht aufnimmt und dann mit euren koppelt. Nutzt ihr für die Datenübertragung dann dieses klassische IoT-Protokoll MQTT?
Richard
Genau. Ich hatte schon angedeutet, dass wir auch fertige Services aus der Cloud nutzen; konkret den IoT-Hub von Microsoft Azure. Die Geräte sind dann über MQTT sowohl auf der Pub/Sub-Seite vom Device-Connector in Richtung Cloud-Connector als auch in Richtung Cloud per MQTT verbunden. Über die dauerhafte Verbindung haben wir auch die Möglichkeit, Funktionen aus der Cloud aufzurufen, angetriggert.
Thomas, du hast gesagt, dass auch Sicherheit in der Entwicklung eine große Rolle spielt. Kannst du das noch mal etwas ausführen? Es ist für viele, die es anwenden, bedeutsam. Warum ist es gerade hier bei den Robotern so wichtig?
Thomas
Ich denke, Sicherheit ist überall bei IoT wichtig, und vor allem in der Industrie. Kunden haben eine starke Anforderung, die Hoheit über die Daten zu behalten, sowie sicherzustellen, das niemand anderes ihre Daten sehen kann. Deshalb ist es nicht nur auf der Feldebene, also wie man mit dem Roboter kommuniziert, sondern über die gesamte Kette hinweg ein wichtiges Thema. Das sollte es überall sein, wenn es um IoT oder Industrial IoT geht.
Richard
Es ist wirklich so, dass unsere Kunden da sensibel sind. Aus den Daten, die die Steuerung bereitstellt oder die wir aus den Robotern auslesen, ist im Prinzip ein Rückschluss möglich auf das, was in der Produktion abläuft. Aber ich bin da ganz guter Dinge und fest überzeugt, dass am Anfang die vermeintliche Gefahr, die der Kunde sieht, sehr groß ist – aber die Kundengespräche zeigen, dass dank unserer Expertise und unseren Lösungswegen dann das Vertrauen da ist, die Lösung auch cloudbasiert umzusetzen.
Wie Thomas angesprochen hat, ist der Cloud Connector genau das Feature, was ich brauche, um diese Entkopplung und Datenverschlüsselung zu realisieren, oder?
Richard
So ist es.
Wir haben über die Datenaufnahme gesprochen. Diese Daten sind jetzt gesammelt im Cloud Connector. Der nächste Schritt wäre, in die Verarbeitung zu gehen, und man muss die Daten der Roboter und der einzelnen Flotten in der Cloud sehen; am besten auch gleich die Auswertung. Wie verwalte ich die ganzen Roboter und was nutzt ihr in der Cloud für die Verarbeitung der Roboterdaten?
Thomas
Wenn man die Kette weiterverfolgt, was passiert mit den Daten – sie nehmen unterschiedliche Wege, je nach geschilderter Kategorie. Grundsätzlich werden erst mal alle Daten plausibilisiert, zugeordnet zum richtigen Kunden. Das ganze Sicherheitskonzept steckt natürlich dahinter. Und dann, wenn man die Zustandsdaten betrachtet – wenn man so will, bauen wir in der Cloud ein digitales Abbild des jeweiligen Roboters auf. Ich will nicht den Begriff des Digital Twin überstrapazieren. Aber im Grunde haben wir zu jedem Roboter ein digitales Abbild, das durch diese Daten aktuell gehalten wird. So wissen wir von jedem Roboter, welche Software-Stände sind installiert? Welche Module oder Tech-Pakete sind installiert? Welche Hardware ist verbaut? Das ist letztlich die Basis dafür, dass der Kunde zum Beispiel über seine Flotte eine Übersicht bekommt und suchen und aggregieren kann – also bestimmte Roboter mit einem bestimmten Stand. Zustandsdaten, die sich vielleicht häufiger ändern, werden natürlich auch als Zeitreihendaten gespeichert, weil man da über die Historie schauen müsste: wie hat sich das verhalten? Wie sieht die Kurve der CPU-Auslastung der letzten Tage aus? Die Meldungen werden indiziert, sodass man gezielt danach suchen kann. Alle diese Daten nehmen je nach umgesetzten Features unterschiedliche Wege in verschiedene Datenbanken und -töpfe. Sie werden zum Teil vorverarbeitet, aggregiert; je nachdem, welches Feature dahinter steht.
Im Endeffekt nehmt ihr die Kategorien an Daten auf – Change Logs, Zustände, CPU-Daten, einfache Condition-Monitoring-Daten – und plausibilisiert diese. Ihr guckt, welche Arten von Daten es sind, packt sie in die einzelnen Töpfe, die es braucht; dann kann ich sie im Asset Manager sehen und verwalten und im nächsten Schritt auswerten?
Thomas
Genau. Plausibilisierung heißt auch: Wenn wir einen bestimmten Datentyp erwarten, ein Datum oder eine Fließkommazahl, dann muss es dem Schema entsprechen. So wird sichergestellt, dass man keine seltsamen Daten aufnimmt und Daten verfälscht.
Wenn man einen Schritt weitergeht – wir haben den Cloud Connector; ich habe alle Daten aus der OT-Welt aufgenommen. Im nächsten Schritt sind wir im Asset Manager: Da sehe ich jetzt alle Roboter, egal ob 5 oder 2000, die sind dort ongeboardet und es geht an die Datenanalyse. Hier kommt eine gewisse Intelligenz hinein, die ihr seitens Device Insight mitbringt. Wie funktioniert das genau? Arbeitet ihr gemeinsam mit euren Kunden und fragt, was für ein Dashboard benötigt wird? Gibt es vorgefertigte Muster?
Thomas
Man kann das in verschiedene Stufen einteilen. Für die Anzeige der Daten, die der Kunde selbst analysieren möchte, bietet das System relativ viel Flexibilität. Das heißt, der Kunde kann sich selbst auch Dashboards zusammenstellen. Die Basis-Dashboards sind in Zusammenarbeit mit Kunden oder nach ihren Anforderungen entstanden. Letztlich kann er sich hier viel selbst konfigurieren oder selbst anschauen. Er kann sich im System etwas herunter-drillen, von der Übersicht in die Details. Auch kann er Condition-Monitoring-Regeln anlegen. Der Schritt weiter, wenn man in Richtung automatischer Analyse von Daten geht, in Richtung Prediction oder Predictive Maintenance, auch mit KI und Machine-Learning-Methoden, ist gerade noch in der Umsetzung. Deshalb können wir heute noch nicht allzu viel dazu sagen. Aber es ist natürlich schon das Ziel, die Daten nicht nur im Ist-Zustand zu bewerten, sondern auch eine mögliche Projektion in die Zukunft zu erreichen – eine Wartung vorherzusagen oder auch eine Anomalie zu erkennen; der Roboter ist verhaltensauffällig. Dem Kunden wird dadurch Arbeit abgenommen, dass er sich nicht immer durch Dashboards durcharbeiten muss, sondern eben mehr Hinweise bekommt, wo man genauer hinschauen müsste. Was bei Daten außerdem ein interessanter Aspekt ist, ist die Integration, da auch iiQoT nicht alles kann und alles können wird. Das ist keine Insel, sondern bettet sich in der Systemlandschaft ein – sowohl beim Kunden als auch bei KUKA. Das heißt ja nicht umsonst Industrial Internet of Things –das Internet impliziert auch eine gewisse Kommunikation und einen Datenaustausch. Auch das wollen wir adressieren. Dafür ist ein gutes Beispiel mit klarem Mehrwert für den Kunden, dass er direkt aus dem System heraus ein Serviceticket anlegen kann, wenn er sieht, da tauchen Meldungen auf oder es gibt ein Problem.
Das heißt, dass ich im Falle eines Services die Schnittstelle zu meinen einzelnen eigenen Systemen habe – sei es unterschiedliche CRM-Systeme, das bindet ihr sozusagen an?
Richard
Genau. Wir haben sicherlich die Möglichkeit, das beim Kunden sichtbar zu machen und auch die Kundensysteme anzubinden. Aber was Thomas gerade sagte, war, dass wir unsere Wissensdatenbank Xpert und unser CRM-System Salesforce nutzen und da einen integrierten Service bereitstellen. Wenn der Kunde eine Meldung oder ein Problem hat und wir zur Lösung unterstützen wollen, ist es überhaupt kein Problem, ein solches Xpert-Ticket zu generieren und die Daten über Xpert in Salesforce zu integrieren. Unsere Serviceexperten können so sofort auf alle Daten zentral zugreifen. So ist es nicht mehr nötig, dass jemand erst vor Ort auftauchen muss. Das Problem kann sofort ausgelesen werden, mit den Zeitreihen, was beim Roboter genau vorgefallen ist. Und die Kollegen aus dem Customer-Service können entsprechend reagieren.
Könnte man das als eine Art App verstehen; eine Software, die einzeln läuft, namens Xpert, worüber ich für den Wartungsfall sicherstellen kann, dass jemand von KUKA den Serviceauftrag direkt bearbeitet?
Richard
Genau, Xpert ist eine Wissensdatenbank, die wir auch so als Service bereitstellen und die viel genutzt wird. Durch die Integration der IoT-Plattform, unseres CRM-Systems Salesforce und Xpert ist diese ganze Datenhaltung, die Information, die beim Kunden vorliegt, bei uns sofort verfügbar. Sie sind zudem verknüpft mit den Lösungen von verschiedenen Zuständen, die in Xpert hinterlegt sind. Die Servicekollegen haben in Xpert auch viele Lösungen für den Kunden und für sich selbst bereit. Da gibt es verschiedene Einstiege in die Datenbank, wodurch es sehr leicht ist, auf die richtige Information zuzugreifen und zu helfen. Für uns ist wichtig, dass die Ausfallzeiten minimal sind, und das ist bei derart zentraler Verfügbarkeit viel leichter, als es vorher war – als man vorher wirklich an die Maschine gehen und vielleicht sogar einen Datenabzug erstellen musste. Ein Beispiel dafür: Wenn es wirklich mal dazu kommt, dass unsere Roboter ausfallen – natürlich sehr selten, denn die Verfügbarkeit der heutigen Automatisierungssysteme ist wirklich sehr hoch. Aber es kommt eben doch mal dazu. Dann kann man im Fehlerfall einen sogenannten Trace File erstellen. Das ist im Prinzip wie ein Oszilloskop. Funktionen, die bereitgestellt werden, die detaillierte Aufzeichnung der Roboterbewegungen, der Achswinkel, die Achsgeschwindigkeiten, Drehmomente, Motorströme. In all das kann man hineinschauen, wie wenn man beim Doktor ist und der ein Stethoskop anlegt. So ähnlich ist es bei uns möglich, mit diesen Trace Files auch bei komplizierteren Problemen sofort helfen zu können. Früher war das ein Riesenthema; weil man es holen musste, von der Maschine, dann mit dem USB-Stick viele Daten transportieren. Dann entstand einfach ein Zeitverzug, und die Ausfallzeiten kosten natürlich bares Geld.
Das heißt, eure Kunden kennen Xpert wahrscheinlich schon länger, nutzen das, und jetzt haben sie die Möglichkeit, diese Daten schnell zu verwerten und direkt über die Cloud verfügbar zu machen. Das ist sicher auch interessant für Sachen wie Versicherungsfälle. Egal was man nachweisen muss, man hat einen Daten-Stack, auf den man immer zugreifen kann? Man muss nicht mehr mit einem USB-Stick rumlaufen und alles manuell zusammenzusuchen.
Richard
Außerdem ist interessant, dass wir auch über die Zykluszeiten und die Energie, die die Systeme aufnehmen, Informationen haben und dazu zukünftig gerne Optimierungsangebote machen wollen.
Thomas
Um das noch zum vorherigen Thema zu ergänzen. Dieses, man läuft mit dem USB-Stick durch die Fabrikhalle, ist eigentlich ein Thema, was man viel größer unter dem Digitalisierungsaspekt sehen würde. Man macht diesen Prozess der Zusammenarbeit zwischen Kunde und Hersteller viel schlanker und effizienter. Man schickt keine E-Mails raus, ruft da noch mal zurück, sondern stellt die entsprechende Information direkt zur Verfügung. Gerade da, wo ein Ausfall enorm Geld kostet, ist die Schnelligkeit viel wert.
Ich glaube das ist ein ganz wichtiger Punkt: Dieser Prozess der Zusammenarbeit ist auch im Endeffekt der Mehrwert – das IIoT bietet ebendiese Möglichkeit der Vernetzung und der Zusammenarbeit.
Ergebnisse, Geschäftsmodelle und Best Practices – So wird der Erfolg gemessen [27:26]
In der Zusammenarbeit mit den Kunden entstehen auch häufig Learnings oder Best Practices, die man nutzen und teilen kann. Könnt ihr ein paar Insights geben, welche Erfahrungen ihr in den Projekten gesammelt habt?
Richard
Grundsätzlich haben wir eine gewisse Vorlaufplanung. Wir führen viele Kundeninterviews, um herauszufinden, wo der Mehrwert des Kunden liegen kann. Zunächst ist es wichtig, zu verstehen, wo der Schmerz liegt, um daraus den Mehrwert abzuleiten. Wir haben normale, typische Vorgehensweisen, wie die Scrum-Methodik. Die kennt, glaube ich, jeder in der Software-Entwicklung. Auch haben wir Product Owner, die mit den Interview-Ergebnissen und Anforderungen ein Backlog vorbereiten und User Storys schreiben, die Entwickler aussteuern – das geht alles quasi im Geradeauslauf.
Jetzt ist spannend: Wenn wir mit den Kunden Demos machen, oder die Möglichkeit geben, das System zu testen – nicht nur wir demonstrieren, sondern der Kunde kann auch testen –, kommen am Ende noch ganz andere Learnings dabei heraus. Ich finde, das ist ein ganz großer Schritt nach vorne, da Präsentation oder eine Demo immer einseitig ist – aber es erlebbar zu machen und das Feedback direkt einzusammeln und agil darauf zu reagieren: das ist das, was wir hier gemeinsam machen. Das funktioniert hervorragend.
Thomas, du bist dann von der Produktentwicklungs-Seite aus daran beteiligt, das zu entwickeln. Wie bindet ihr das Feedback zur Plattform direkt ein?
Thomas
Es ist sehr wichtig, dass man das in frühen Phasen schon macht. Sich nicht erst drei Jahre einschließt und dann mit der tollen Plattform aus dem Kämmerlein kommt. Wir haben eine explizite Evaluationsplattform, die kein reines Demo-System ist, sondern bei der Echtdaten einfließen. Das ist im Bereich IoT wichtig, dass man die gesamte Kette durchspielt, da die Daten letztlich doch manchmal etwas anders aussehen, als man sich das vielleicht vorstellt. Das haben wir hier so umgesetzt. Ein anderes Learning, das wir hier auch teilen können –ein Learning, das wir bei Device Insight insgesamt haben, aber auch in diesem Projekt: Auf bestehende Standards aufsetzen und vor allen Dingen auch Komponenten und Services benutzen, die schon da sind. Man sollte nicht an falschen Stellen das Rad neu erfinden, sondern Dinge nutzen, die es schon gibt, um sich auf das Wesentliche zu konzentrieren und den Mehrwert für den Kunden herauszuarbeiten.
Wir haben speziell zum Thema Standards gemeinsam mit der KUKA eine Folge unseres IoT Industry Bartalk gestaltet. Da geht es genau darum, wie kann man Standards nicht nur im Shop-Floor, sondern auch in der IIoT-Welt nutzen, um skalierbare Systeme aufzubauen? Was kommt denn da noch; wo wollt ihr hin und auf welche Features dürfen wir gespannt sein?
Richard
Wir haben ja schon erwähnt: Asset Management, Condition Monitoring, Preventive Maintenance und Remote Monitoring. Das sind die vier Use Cases, die wir besprochen haben. Was zukünftig kommen wird, ist ein Condition-based Maintenance. Wir wollen auf die sogenannte Anomalie-Detektion hinaus. Mit den Daten- und Zeitreihen ist es ja nicht nur möglich, rückwärtszuschauen; sondern mit der künstlichen Intelligenz, mit dem Domainwissen – wie gut wir unsere Systeme kennen, nebst deren typischem Fehlverhalten und möglichen Ausfällen – ist es auch möglich, nach vorne zu rechnen. Wir würden den Zustand gerne so nah monitoren, dass wir rechtzeitig reagieren können, zum Beispiel ein nötiges Bauteil tauschen oder Ähnliches. Oder bei Taktzeitanalysen oder Energy Consumption Hilfestellung geben, wie man das besser aufstellen kann. Es ist wichtig, dass man als Roboterhersteller sein Domainwissen einsetzt, um beim Kunden Verbesserungen zu platzieren, die der Kunde sonst nicht gleich heben kann – was nun durch die Daten ermöglicht wird. Backup-Management ist auch immer noch ein Thema, weil viele von den Steuerungen sehr wichtige Programme enthalten. Das ist natürlich eine häufige Anforderung. Wir wollen unsere Customer Journey vereinheitlichen. Wir haben die IoT-Platform Xpert und Salesforce schon verbunden. Und es gibt noch weitere Themen wie my.KUKA und so weiter – dass es für den Kunden EINE Experience wird … EIN Login, um mit den verschiedenen Angeboten und Möglichkeiten zu interagieren.
Predictive Maintenance – alle sprechen darüber, aber das ist ja die Königsdisziplin, die noch on top kommt, wenn man die Daten in entsprechender Datenqualität verfügbar hat. In die intelligente Auswertung zu gehen, neue Features hochzubringen und das mit dem Kunden gemeinsam weiterzuentwickeln.
Übertragbarkeit, Skalierung und Nächste Schritte – So könnt ihr diesen Use Case nutzen [32:18]
Thomas, ihr seid als Device Insight mit ganz unterschiedlichen Projekten unterwegs. Ihr arbeitet auch mit der Firma RAFI zusammen, mit Costa Coffee, habt unzählige weitere Projekte. Wie ist das mit dieser Plattform? Ihr habt sie speziell für KUKA entwickelt; aber lässt sich das auch auf andere Kunden übertragen?
Thomas
Die Herausforderungen und die Inhalte sind schon ganz gut übertragbar, da die Rahmenbedingungen im Bereich Shop Floor und Industrie – anders als in anderen Kontexten wie etwa Smart Home – recht ähnlich sind, insbesondere die grundsätzlichen Technologien oder Vorgehensweisen. Gerade bei der Datenverarbeitungskette – wie erfasse ich Daten, was passiert damit, wie kommen die in die Cloud? – ist es ein ähnliches Konstrukt, was man auch in anderen Systemen findet. Das ist auch der Grund, warum wir mit der KUKA bei dem Produkt zusammenarbeiten und das unterstützen. Viele Use Cases, wenn man an Asset Management und Übersichten und Aggregation und Zeitreihen denkt, sind doch relativ ähnlich. Da geht es in immer speziellere Use Cases rein, die vielleicht einen Roboter betreffen. Predictive Maintenance ist da komplett anders als in anderen Bereichen. Aber die Basis sieht doch immer sehr ähnlich aus. Da haben wir Best Practices bei uns etabliert, was letztlich eine wiederverwendbare Architektur darstellt.
Das ist dann die Basis, wenn ich ein Werkzeugmaschinenhersteller bin, oder egal aus welchem Umfeld: Ich kann mit euch zusammenarbeiten und das gemeinsam entwickeln. An der ganzheitlichen IIoT-Plattform für die Roboter-Flotten sieht man sehr schön, was heute schon möglich ist. Wer mit euch an der ein oder anderen Stelle tiefer ins Detail gehen möchte, findet die Kontaktdaten in den Shownotes.
