Ist das eine „Stanze“ oder ein „Stanzer“?

Die Fachsprache im Betrieb ist kompliziert und oft nicht eindeutig.

Viele Hersteller liefern ihre Verarbeitungs- und Verpackungsmaschinen an internationale Kunden. MADDOX soll für denselben Maschinentyp in unterschiedlichen Sprachen funktionieren. Wir werden deshalb oft gefragt, ob wir das enthaltene Wissen auch automatisch in andere Sprachen übersetzen können. Die Antwort lautet ja: Eine Schnittstelle zu DeepL, dem derzeit besten Übersetzungswerkzeug auf Basis Maschineller Lernverfahren, steht weit oben auf unserer Roadmap.

Doch was, wenn es eine weitere Sprache in jedem Unternehmen gibt?

In allen Betrieben existiert eine eigene Sprache, die von den Mitarbeitern mit der Zeit ständig weiterentwickelt wird. Maschinenbediener nutzen selten die Fachbegriffe für Maschinenteile, die Konstrukteure in den Handbüchern niedergeschrieben haben. Letztere stehen oftmals bei der Technik und werden nicht auswendig gelernt. Stattdessen wird ein Bediener im Normalfall von einem erfahrenen Kollegen geschult, der ihm die Maschine erklärt und zeigt. Neue Mitarbeiter müssen viel Zeit investieren, um diese Sprache zu lernen. Im Laufe der Berufserfahrung kann der genaue Wortlaut der Fachbegriffe auch von Technikern vergessen oder abgeändert werden. Zu lange Begriffe werden abgekürzt. Aus „Packmittelhaltefinger“ und „Transferfinger“ werden „Haltehebel“ und „Transferhebel“, der eine hält das Packmittel, der andere bewegt es weiter. Unbekannte Teile erhalten Namen nach ihrem charakteristischen Aussehen oder ihrer Hauptfunktion. Manchmal werden so ganz unterschiedliche Teile gleich oder sehr ähnlich betitelt, z.B. „Stanze“ und „Stanzer“. Da kann es leicht zu Verwechslungen kommen.
Für eine Nutzerbefragung in der Fabrik eines unserer Pilotkunden arbeiteten wir zunächst Maschinenhandbücher durch. Um das Maschinenverständnis der Nutzer zu verfassen, ließen wir uns anschließend die Maschinen von Technikern, Maschinenbedienern und Schichtleitern genau erklären. Dabei zeigte sich schnell, dass Nutzer ein unterschiedliches Verständnis vom Aufbau und Funktionsweise einer Maschine haben und viele verschiedene Begriffe für eine Komponente existieren. Für ein Bauteil, das Luft pustet, haben wir viele Bezeichnungen gehört, u.a. „Pusteröhrchen“, „Blasrohr“ und „Lüfterstange“. Auch die Bänderbezeichnung ist ein gutes Beispiel. Während Techniker Bänder nach Handbuch zählten, nämlich von hinten nach vorn, nummerieren Maschinenbediener die Bänder, so wie sie üblicherweise vor der Maschine stehen. So geben sie dem Band, was ihnen am nächsten ist, die Zahl 1 und nummerieren dann nach hinten durch. Das kann natürlich zu Missverständnissen führen.

MADDOX verbessert die betriebliche Kommunikation

In Kooperation mit Ingenieurspsychologinnen haben wir verschiedene Funktionen entwickelt, mit denen MADDOX nicht nur den Austausch zur Störungsbeseitung ermöglicht, sondern auch die Qualität der Kommunikation verbessert:

  • Zum Dokumentieren von Störungen und Lösungen lassen sich einfach Fotos aufnehmen und mit Text oder Fingerskizzen annotieren. Auch das Aufzeichnen und Einfügen von Video- und Audioaufnahmen ist leicht möglich. Dadurch kann in vielen Fällen die oftmals missverständliche verbale Beschreibung entfallen.
  • Unsere Algorithmen auf Basis Maschineller Lernverfahren behandeln Wissensinhalte als „Container“ – unabhängig vom jeweiligen Inhalt. Dadurch werden bislang kaum suchbare Inhalte, wie Fotos und Videos, genauso gut gefunden, wie Text. Eine fehleranfällige und umständliche Verschlagwortung ist nicht notwendig.
  • Das Konzept der möglichst visuellen Arbeitsweise nutzen wir auch für die Lokalisierung von Störungen: Auf einem hinterlegten Foto oder Schema der Anlage lässt sich der Störungsort grafisch markieren und dadurch unmissverständlich dokumentieren.
  • MADDOX präsentiert gespeichertes Wissen in einer Struktur und Reihenfolge, die gezielt das Verständnis befördert und Missverständnisse vermeidet. Beispielsweise wird im Störungsfall zunächst eine Störungsbeschreibung ausgegeben, um ein gemeinsames Problemverständnis zu erzeugen und nicht eine richtige Lösung auf’s falsche Problem anzuwenden.

Wir brauchen eine Anbindung an unser Elektronisches Schichtbuch. Das ist aber eine Eigenentwicklung…

(Kunde)

Das Forschungsprojekt zur Unterstützung von Maschinenrüstung und -wartung läuft gut. Die Ergebnisse könnten sich künftig gut als Erweiterung von MADDOX nutzen lassen…

(Fraunhofer IVV)

Kundenspezifische Wünsche und die zukünftige Integration neuer, innovativer Lösungen treiben von Anfang an unsere Produktentwicklung. Doch wie können wir diese jetzt schon berücksichtigen, obwohl ihre genauen Anforderungen noch gar nicht bekannt sind?

Unsere Lösung ist modulares System auf Basis einer Service-Architektur. In unserer Software laufen Kernmodule, Erweiterungsmodule und kundenspezifische Module als weitgehend eigenständige Teilprozesse. Dies macht das Gesamtsystem resilient und sehr flexibel. Aber wie lässt sich dieser “Zoo” im Griff halten? Ganz ähnlich wie ein Projektteam menschlicher Kollegen: Jeder arbeitet weitgehend eigenständig. Um sich gegenseitig zum Gesamtprojekt auf dem Laufenden zu halten, nutzen sie Newsletter, die je nach Informationsbedarf abonniert werden können.

Wir setzen das gleiche Prinzip technisch mit dem Message Broker NATS um. Unsere einzelnen Module senden Nachrichten in den zentralen Broker, die von den jeweils anderen Modulen abonniert werden können. Dadurch können sich zukünftige Module einfach einklinken und die für sie relevanten Nachrichten abonnieren, ohne dass Änderungen am bestehenden System notwendig sind. Dies ermöglicht eine effiziente Entwicklung trotz unbekannter zukünftiger Anforderungen.

“Aber der neue Quasi-Industriestandard ist doch MQTT…”

Das stimmt, aber wir setzen den Message Broker nur zur Kommunikation zwischen den einzelnen Prozessen auf unserer Maschine ein. Hier kommen die typischen Stärken von MQTT, wie beispielsweise die zuverlässige Übertragung über unzuverlässige Netzwerke, nicht zum tragen, während NATS seine Vorteile ausspielt. Dazu zählt beispielsweise seine enorme Geschwindigkeit, die wir für schnelle Übertragung großer Mengen von Maschinendaten brauchen. Für die Kommunikation nach außen setzen wir – ganz im Sinne der Microservice-Architektur – auf eigenständige, protokollspezifische Module; beispielsweise für OPC UA…und bei Bedarf selbstverständlich auch für MQTT 😉