In der Industrie 4.0 verspricht Predictive Maintenance optimierte Wartungsprozesse und damit eine ganze Reihe von Vorteilen: höhere Produktivität, gesteigerte Qualität, sinkende Produktionskosten und eine Abdämpfung der Auswirkungen des Fachkräftemangels. Zusammen mit der ESW Group forscht ein inovex-Team bestehend aus Studierenden und Mitarbeiter:innen im Bereich Predictive Maintenance. Der konkrete Use Case: Im BMWK-geförderten Forschungsprojekt Service-Meister arbeiten sie an der KI-gestützten Optimierung von Instandhaltungsprozessen in der industriellen Produktion.
Die ESW Group ist ein mittelständisches Industrieunternehmen, das verschiedene Verbindungselemente für die Automobilindustrie herstellt. Ihr Fachbereich sind unter anderem Kaltumformung und Stanztechnik. Im Rahmen des Service-Meister-Projekts entsteht ein intelligentes Service-Ticket-System für die Wartung ihrer Maschinen. Im ersten Teil stellen wir die Herausforderungen und das zusammen entwickelte Konzept vor, bevor wir im zweiten Teil diskutieren, was das Service-Ticket-System “intelligent“ macht.
Von Excel zum intelligenten Service-Ticket-System
Um Instandhaltungsaufträge an Industriemaschinen zu organisieren, verwendete ESW bislang ein intern entwickeltes Tool in Excel und einen darum gestalteten manuellen Prozess. Trat ein Problem an einer Maschine auf, wurde von dem Anlagenführer ein Instandhaltungsauftrag (IHA) über dieses Tool aufgegeben. Der IHA enthielt verschiedene Informationen, darunter eine Problembeschreibung, die von den Anlagenführern vermutete Fehlerkategorie, also zum Beispiel ein mechanischer oder elektronischer Fehler, einen Zeitstempel und die Dringlichkeit. Die Daten wurden anschließend in einem Excel Dokument gespeichert und ein Techniker per E-Mail benachrichtigt. Der Techniker hatte eine eigene Ansicht in Excel, in der alle momentan offenen Aufträge sichtbar waren. Nach Erledigung eines Auftrages wird hier anschließend auch eine Problemlösung hinterlegt.
Dieser manuelle Prozess zur Meldung und Durchführung von IHAs erzeugt nicht nur erheblichen organisatorischen Aufwand, sondern ist auch besonders anfällig für Fehler.
Im Rahmen des Service-Meister-Projekts arbeitet inovex zusammen mit der ESW Group und der Berliner Hochschule für Technik an einem Intelligenten Service-Ticket-System (ISTS), das den bisherigen Prozess zur Meldung und Bearbeitung von IHAs erheblich optimieren soll.
Hier werden sowohl Anlagenführer:innen, als auch Techniker:innen bei der Aufgabe und Bearbeitung von IHAs durch Algorithmen der künstlichen Intelligenz unterstützt. Das System ist über ein benutzerfreundliches Design leicht zugänglich und integriert verschiedene intelligente Algorithmen aus dem Bereich des maschinellen Lernens zur Unterstützung des Users. Eine intelligente Suche unterstützt Anlagenführer:innen und Techniker:innen bei der Eingabe von Problembeschreibungen und Lösungen. Das Klassifizieren eines Problems wird durch einen KI-generierten Vorschlag unterstützt. Außerdem ist die Generierung von Lösungsvorschlägen intelligenter gestaltet. So können Ressourcen gespart und Verzögerungen bis zur Reparatur aufgrund von fehlerhaften Eingaben verhindert werden.
Lösungskonzept
Das ISTS besitzt eine Ansicht für Anlagenführer:innen, um einen Wartungsauftrag schnell und einfach aufzugeben. Des Weiteren gibt es eine gesonderte Ansicht für Techniker:innen, in der alle noch offenen und bereits abgeschlossenen Aufträge aufgelistet sind. Jeder Wartungsauftrag erhält eine eigene Ansicht, in der Techniker:innen den Auftrag bearbeiten und abschließen können. Um einen Auftrag abzuschließen, muss man eintragen, in welche Kategorie der Fehler fällt und ihn mit dem Lösungsansatz versehen, der schlussendlich den Fehler behoben hat. Um Anlagenführer:innen bzw. Service-Techniker:innen im Instandhaltungsprozess zu unterstützen, wurden verschiedene intelligente Services implementiert, die im Rahmen eines zweiten Blogposts ausführlich vorgestellt werden.
Das Ticketsystem wurde als klassische Webanwendung implementiert, da in den Produktionshallen hauptsächlich mit Windows betriebene Rechner als Terminals zur Verfügung stehen. Zudem nutzen die Mitarbeitenden keine Smartphones im Produktionskontext und mehrere Anlagenführende teilen sich ein Terminal. Daher ist die Webanwendung die beste Möglichkeit, um das ISTS für alle Mitarbeitenden zugänglich zu machen.
Zur Implementierung des Frontends wird Flutter mit Dart als Programmiersprache verwendet. Flutter ist eigentlich ein Framework für die Cross-Platform-Entwicklung. Das Prinzip basiert auf einer gemeinsamen Codebasis für alle generierten Anwendungen. Momentan wird Flutter hauptsächlich in der App-Entwicklung eingesetzt. Allerdings bietet das Tool auch die Möglichkeit, eine Web-App zu entwickeln. Im Rahmen dieses Forschungsprojekts ergibt sich daher die Chance zu testen, wie gut Flutter mittlerweile auf die Entwicklung von Webanwendungen ausgelegt ist. Außerdem kann mit Flutter bei Bedarf in Zukunft auch mit wenig Aufwand eine App für iOS oder Android mitgebaut werden. Für das State Management wurde Riverpod verwendet. Riverpod ermöglicht einen einfachen Einstieg, erkennt Programmierfehler bei der Kompilierung und ist testbar. Zudem realisiert Riverpod auch das Aktualisieren der Oberfläche, abhängig von asynchronen Zuständen – ein großer Vorteil bei HTTP Requests.
Gehostet wird das ISTS auf der Google Cloud Platform (GCP). Sie bietet eine Reihe von Tools, welche die grundlegende Infrastruktur von Webapplikationen verwalten. Google managt auch die nötige Hardware, auf der das ISTS läuft. Daher fällt ein Großteil vom administrativen Aufwand weg.
Das ISTS wird als eine Microservice-Architektur konzipiert. Jedes Teil des Systems läuft als eine eigenständige Instanz auf GCP. Beispielsweise ist das Frontend in einer eigenen Instanz gekapselt, und die Kommunikation mit dem Backend (welches analog in einem separaten Service gelagert ist) erfolgt dann über eine REST-API.
Insgesamt gibt es 4 Microservices: das Frontend, das Backend, einen Training-Service sowie eine MLFlow Instanz. Der Quellcode für jeden Microservice wird in GitLab verwaltet und mittels GitLabs CI/CD Pipelines auf GCP deployt. Sogar die Datenbasis wird mittels GCP Ressourcen (genauer gesagt eine Kombination von Cloud SQL Datenbanken und Cloud Storage Buckets) gemanagt.
Mehr Details zu den einzelnen Services und die Datenpersistierung folgen in Teil 2 der Blogpost-Reihe.
Login und Rollen
Um Webanwendung vor Unbefugten zu schützen, haben wir einen Login-Screen implementiert. So müssen sich die Benutzer:innen gemäß ihrer Rolle authentifizieren und erhalten auf entsprechende Komponenten Zugriff.
Es gibt drei Rollen, die festlegen, welche Aktivitäten ein User in der App durchführen kann. Das Rollenmanagement der App ist hierarchisch, die übergeordnete Rolle kann alle Aktivitäten der untergeordneten Rollen ausführen:
- Maschinenführer:innen befinden sich auf der ersten Ebene der Hierarchie. Sie können Instandhaltungsaufträge erstellen und die Liste der bestehenden Aufträge einsehen.
- Techniker:innen können Instandhaltungsaufträge bearbeiten. Das heißt, sie können die Arbeit an einem Auftrag beginnen, indem sie sich diesem zuordnen, den Auftrag bearbeiten, indem sie eine Lösung für das Problem hinzufügen und den Auftrag schließen, nachdem das Problem gelöst wurde.
- Teamleiter:innen können geschlossene Aufträge wieder öffnen und/oder die Auftragsdetails (z. B. Problembeschreibung oder Lösung) ändern, nachdem das Ticket geschlossen wurde.
Instandhaltungsaufträge aus der Sicht von Anlagenführenden
Um einen neuen Instandhaltungsauftrag zu erstellen, können User mit der Rolle „Anlagenführer:in“ im Kontextmenü die Option „Instandhaltungsauftrag erstellen“ auswählen. Danach müssen sie ihren Namen aus einem Dropdown auswählen und anschließend den Arbeitsplatz. Haben sie einen Arbeitsplatz ausgewählt, werden bereits ähnliche oder häufige Probleme vom Backend abgefragt und angezeigt. Sie können dann eines dieser Probleme auswählen oder eine eigene Problembeschreibung in das dafür vorgesehene Feld eintippen. Auf Basis der gewählten oder getippten Problembeschreibung werden dann noch zusätzliche Vorschläge angezeigt, die User auswählen können. So wird die Auswahl einer Problembeschreibung erheblich vereinfacht und führt zu einheitlichen Beschreibungen, die wiederverwendet werden können.
Zusätzlich werden den Nutzer:innen noch Kategorie-Wahrscheinlichkeiten angezeigt, sobald sie eine Problembeschreibung eingetippt oder ausgewählt haben. Das sorgt dafür, dass an dieser Stelle weniger Fehler gemacht werden und sich die Aufträge später besser zuordnen lassen.
Haben die User eine Beschreibung ausgewählt oder selbst eingetippt, müssen sie noch die restlichen Felder, wie z.B. „Fälligkeit“, ausfüllen und dann die Auftragserstellung abschließen. Eine neuer Auftrag wird dann an das Backend geschickt. Im nachfolgenden Flow-Diagram wird dieser Ablauf noch einmal genauer dargestellt.
Um Nutzer:innen bei der Erstellung des Auftrags etwas zu anzuleiten, gibt es insgesamt drei Screens, die durch das Herunterschalten erreicht werden können. Im ersten Screen wählen sie Namen und den Arbeitsplatz. Außerdem bekommen sie für diesen Arbeitsplatz die häufigsten und zuletzt aufgetretenen Probleme angezeigt und können hier schon direkt eine Problembeschreibung auswählen.
Im nächsten Screen können User eine Problembeschreibung eintippen oder bekommen die bereits ausgewählte Beschreibung angezeigt und kann dies bearbeiten. Sobald eine Eingabe in das Problembeschreibung-Feld erfolgt ist, bekommen sie zusätzlich noch „Ähnliche Probleme“ für diese Beschreibung angezeigt. Für die Problembeschreibung müssen sie noch eine Kategorie auswählen.
Im abschließenden Screen können die User dann noch den Rest des Formulars ausfüllen und den Instandhaltungsauftrag melden.
Instandhaltungsaufträge aus der Sicht von Service-Techniker:innen
Die User Rolle „Techniker:in“ kann sich über eine Übersichtsseite wie in der nachfolgenden Abbildung einen Auftrag auswählen, um diesen zu bearbeiten und dann abzuschließen. In der Übersicht werden den Nutzer:innen alle wichtigen Infos angezeigt und sie können gezielt nach Auftragsstatus oder Fälligkeit filtern. Außerdem können sie über die Suchleiste nach bestimmten Aufträgen suchen. Die Aufträge unterscheiden sich in ihrer Farbe nach Status. Offene Aufträge sind grün markiert und haben einen Startbutton. Aufträge, die sich in Bearbeitung befinden, haben einen Edit-Button und sind grau unterlegt. Oben Links gibt es einen Toggle-Switch, mit dem sich Nutzer:innen bereits abgeschlossene Aufträge wie in Zeile drei anzeigen lassen können.
Haben sie einen ‘offenen’ Auftrag ausgewählt und möchten diesen starten, müssen User zuerst ihren Bearbeiter:innen-Namen auswählen und der Auftrag wird auf den Status ‘in Bearbeitung’ gesetzt. Dabei wird der Startzeitpunkt automatisch festgelegt. Anschließend können sie den Auftrag bearbeiten. Dazu müssen sie eine Lösung hinzufügen und können die von dem/der Anlagenführer:in ausgewählten Kategorien noch einmal ändern. Ähnlich wie bei den Problembeschreibungen werden den Usern auch hier Lösungsvorschläge nach Häufigkeit und Historie angezeigt oder nach Ähnlichkeit, sofern sie eine Eingabe in das vorgesehene Lösungsfeld getippt haben. Im nachfolgenden Diagramm wird der Prozess noch einmal genauer dargestellt:
Beim Bearbeiten eines Auftrags werden die User initial auf den Lösungs-Screen geleitet, können aber durch Hochscrollen auch die Angaben, die beim Erstellen des Auftrags getätigt wurden, einsehen. Wenn ein:e Techniker:in das Problem gelöst hat, schließt er/sie den Auftrag ab und muss noch einen Endzeitpunkt eintragen. Die Oberfläche für die Bearbeitung sieht dann so aus:
Zusammenfassung
Im Forschungsprojekt „Service-Meister“ entwickelte die ESW-Gruppe gemeinsam mit inovex und der Hochschule für Technik Berlin ein intelligentes Service-Ticket-System für die Wartung ihrer Maschinen. Das ISTS soll die bisherige manuelle Vorgehensweise mit Excel ablösen und Maschinenführer:innen sowie Techniker:innen bei der Erstellung von Instandhaltungsaufträgen unterstützen. Das System verfügt über ein nutzungsfreundliches Design und integriert intelligente Algorithmen aus dem Bereich des maschinellen Lernens. Es verfügt über unterschiedliche Ansichten für Maschinenführer:in und Techniker:in.
