CheckMATE – Erfahrungsmanagement für ServiceRoboter zur Realisierung von Self-Healing in Produktionsanlagen [Projektbericht] Markus Nick, Sören Schneickert Jürgen Grotepaß Fraunhofer Institute for Experimental Software Engineering (IESE) Freudenberg FDS GmbH & Co KG Fraunhofer-Platz 1, 67663 Kaiserslautern Weinheim {markus.nick, soeren.schneickert}@iese.fraunhofer.de [email protected] Systeme, die exakte Problemursachen analysieren und Abstract. In der produzierenden Industrie – diese in Korrelation zu bereits in der Vergangenheit insbesondere in der Pharma-, Automobil- und aufgetretenen Fehlermustern setzen können, gibt es Zulieferindustrie – steigen die Qualitätsanforderungen aufgrund der Heterogenität unterschiedlicher in Richtung Null-Fehler-Produktion. Als Antwort Messsysteme und auch oft fehlender kommen zunehmend automatische Verfahren zur Prozesstransparenz derzeit noch keine [4]. Fehlerbehebung und Fehlervermeidung in der Zielstellung von CheckMATE ist die Erkennung und Produktionskette zum Einsatz. Integrierte QualitätsZuordnung von Defekten zur verursachenden und Prozessdaten von Sensorsystemen und Prozessstufe, sodass mit Hilfe der CheckMATEAnlagensteuerungen stellen hierfür die Basis dar Service-Roboter Regelkreise entstehen (Bild 1), die zu (Projekt BridgeIT1). Im Projekt CheckMATE2 soll standardisierten Qualitätsrichtlinien für Teilprozesse nunmehr Beziehungen von prozessbegleitend führen. Die hierdurch entstehende Transparenz führt gewonnenen Qualitätsdaten mit Erfahrungswissen zur Vereinheitlichung von Konzernrichtlinien der hergestellt werden, so dass kleinste einzuhaltenden Prozess- und Produktqualitäten an den Qualitätsregelkreise konfiguriert werden können. Schnittstellen beteiligter Fertigungsstufen. Dazu werden aus Defekttrends (Defekterfahrungen) Steuerparameter für einen lernfähigen Serviceroboter ermittelt, der Prozesslageabweichungen im Prozess automatisch behebt. Hiermit wird ein Self-HealingVerfahren zur Kompensation von Prozessdrifts umgesetzt. Während der Evaluierungsphase des Prototypen im industriellen Pilotprozess wurden innerhalb von 2 Monaten mehr als 80 Defekterfahrungen akquiriert, die 2007 im statistischen Dauertest innerhalb der Fertigungsumgebung verifiziert werden.

Einleitung Automatische, prozessintegrierte Systeme zur Qualitätskontrolle gewinnen in nahezu allen Industriezweigen vor dem Hintergrund der Null-FehlerForderung zunehmend an Bedeutung. Während in diesem Kontext die Entwicklung optischer Technologien und Sensorprinzipien bis vor kurzem durch nationale Forschungsschwerpunkte bzw. solche im 4. und 5. EU Rahmenprogramm (IST, GROWTH) bestimmt wurden und zum Einsatz von lokalen (punktuellen) Bildverarbeitungsbzw. Oberflächeninspektionssystemen zur Qualitätskontrolle (Stahl-, Papier, und Textilindustrie) geführt haben, definieren die jetzt eröffneten erweiterten Rahmenbedingungen Impulse zur Softwareentwicklung für die Integration dieser heterogenen Systeme. Die Integration und intelligente Auswertung der Datenströme heterogener Sensorsysteme eröffnet ganz neue Möglichkeiten Rückschlüsse auf defektverursachende Bedingungen zu ziehen. Insbesondere werden auch prozessschrittübergreifende Schlussfolgerungen so erst möglich.

1

Das BridgeIT-Projekt (http://www.BridgeIT.de/) wird vom Bundesminsterium für Bildung und Forschung gefördert. 2 Das CheckMATE Projekt (www.checkmate-online.de) wird vom Bundesminsterium für Bildung und Forschung gefördert.

-1-

Bild 1: Kleine (im CheckMATE-Roboter integrierte) innerhalb der Fertigungsstufen führen zur Prozessoptimierung.

Regelkreise

Die Entwicklungen in CheckMATE spiegeln u.a. den Bedarf der deutschen Industrie gemäß einer Studie von McKinsey wieder [6]. In dieser Studie wurde die automatische Fehlerbehebung und -vermeidung als eine der wesentlichen Herausforderungen identifiziert, die in den kommenden Jahren von der Industrie anzugehen ist. Die Basis hierfür bilden objektive Qualitätsdaten, d.h. Sensordaten für Teilequalität und Anlagenzustand, angereichert mit Informationen zum Anlagenstatus und zum Kontext (Artikel, Auftrag, …). Die semantische Integration dient der Zuordnung von Sensordaten zu produzierten Teilen, um Zusammenhänge zwischen Anlagenzustand und Qualität der produzierten Teile erkennen zu können. In CheckMATE werden solche Daten mit Erfahrungswissen kombiniert und schaffen so die Grundlage zur Realisierung einer möglichst automatisch geregelten Anlage. Rückfragen an Werker oder Produktionssteuerer erfolgen nur dann, wenn die Erfahrungen zur Regelung im aktuellen Kontext noch nicht hinreichend valide sind. Es werden zunächst Anwendungsszenarien für den Self-Healing-Ansatz von CheckMATE vorgestellt. Daraufhin wird auf Self-Healing im Kontext adaptiver Anlagenregelungen eingegangen, um dann das Self-

Healing-Verfahren unter Verwendung der Defekterfahrungen vorzustellen. Dann wird auf die Integration des Verfahrens mit Sensorik und Aktorik eingegangen. Schließlich wird die Defekterfahrungsakquisition erläutert. Abschließend wird zusammengefasst, der Projektstatus dargestellt und ein kurzer Ausblick gegeben.

Anwendungsszenarien Die CheckMATE-Maschinenprofile decken Anwendungsfälle in der Automobilindustrie (Prozessintegration an Schnittstellen der Blechumformung in Presswerken, und der Bearbeitung bzw. Montage im Rohbau) und der Zulieferindustrie (Prozessintegration an Schnittstellen von Kunststoffspritzguss-Fertigungslinien) ab.

Aus den Defektbildern gewonnene Merkmale kennzeichnen im Vergleich mit Daten aus optimaler Produktion die Stellgrößen für kleinste Regelkreise (Bild 3). Self-Healing kompensiert somit die erkannte Abweichung der Prozesslage und reduziert die aufgetretene Varianz. In der Regelungstechnik gibt es bereits Konzepte für adaptive Regelungssysteme, die die Basis für SelfHealing bilden können. Ein Modell für ein solches adaptives Regelungssystem ist der Self-Tuning-Regler [3]. Wir haben diesen Regler-Typ für eine adaptive, erfahrungsbasierte Regelung angepasst und verfeinert (Bild 4). Identifikation/Lernen von neuen Erfahrungen

//

Identifikation mit Produkt-/Modell-Wechseloption - Konfiguration Regelglied gem. Produkt u. Erfahrungen - Lernen neuer Erfahrungen RohmaterialVariationen (z1)

Werker, Einrichter

w1: Produktspezifikation w2: Rohmaterial-Parameter

w3: Qualitätsspezifikation

Reglermodifikation

e

Regelglied für Prozessparameter Aktion

(noch) nicht bekannte Umgebungsparameter

u1..n Prozessparameter

Situation

Steller

Produktionszelle / Mensch

Qualität des produzierten Teils

Zustandsinspektion Qualitätsinspektion

r: Qualitätsdaten Situation

(z.B. automatische Sichtkontrolle)

Anwendung und Validierung von Erfahrungen

Bild 4: Erfahrungsbasiertes (Blockschaltbild-Notation [3]) Bild 2: Roboterbasierte Artikelund Werkzeugkontrolle im Fertigungsprozess. Der Artikel wird im Greifer zur Inspektion rotiert und gewendet. Die Priorität der Inspektion liegt auf der Detektion von Serienfehlern vorgelagerter Fertigungsprozesse.

Self-Healing für geregelte Anlage

eine

adaptiv

Unter Self-Healing verstehen wir eine möglichst automatische und zuverlässige Defektbehebung sowie Defektvermeidung. Dazu analysiert der CheckMATERoboter Fehlerbilder und Trends. Lassen diese z.B. auf akute Werkzeugfehlfunktion (Æ Defektbehebung) oder Werkzeugverschleiß (Æ Defektvermeidung) schließen, reagiert er direkt und stellt sich durch Werkzeugwechsel „von selbst“ optimal ein.

Bild 3: Defekttrends werden als Feedback für den Prozess ausgewertet. Merkmalbasiert werden Prozesslageabweichungen kompensiert.

-2-

adaptives

Qualitäts-Regelungssystem

Zur Realisierung dieses erfahrungsbasierten adaptiven Qualitätsregelungssystems werden die folgenden KIVerfahren eingesetzt oder sollen eingesetzt werden: Das Regelglied setzt die Prozessparameter unter Verwendung einer Kombination von Fuzzy-Regeln mit Case-Based-Reasoning für die erfahrungsbasierte Fehlverhaltens-/Defekterkennung und –behebung. Für letzteres werden sogenannte Defekterfahrungen verwendet. Zur Validierung dieser Defekterfahrungen wird das Experience-Feedback-Loop-Verfahren verwendet [7]. Die sogenannte Identifikation konfiguriert das Regelglied für unterschiedliche Produkte und Rohmaterialien. Hierfür wird ein fall-basiertes Konfigurationsverfahren verwendet werden. Für die Entdeckung neuer oder verwandter Erfahrungen sollen Verfahren des maschinellen Lernens untersucht werden. Der Schwerpunkt der bisherigen Arbeiten lag auf dem unteren Regelkreis, in dem die Defekterfahrungen zur Regelung der Produktionszelle verwendet werden (Beispiele für Defekterfahrungen siehe Bild 5). Dieser Regelkreis mit den Defekterfahrungen realisiert auch das eigentliche Self-Healing, während der andere Regelkreis „lediglich“ zur Adaption der Anlage bei einem Produkt- oder Rohmaterialwechsel dient, d.h. zur Rekonfiguration bzw. Selbstkonfiguration der Produktionsanlage bei einer Änderung des Kontextes. Daher wird auf den Defekterfahrungsregelkreis nunmehr im Detail eingegangen.

Self-Healing mit Defekterfahrungen Für das Self-Healing im Regelkreis wird der Experience-Feedback-Loop [7] als Erfahrungsmanagement-Ansatz in Kombination mit Case-based Reasoning (CBR) [1] als KI-Technologie eingesetzt. Auf der Prozessebene ist der ExperienceFeedback-Loop einerseits mit technischen Regelkreisen und andererseits mit CBR kompatibel [7]. CBR hat sich bereits als KI-Ansatz zur technischen Diagnose bewährt (z.B. Anwendungsfälle für Fehlerdiagnose bei Flugzeugtriebwerken, Druckmaschinen und anderen technischen Geräten [2]). Der Experience-Feedback-Loop ergänzt CBR um die automatische Pflege eines Validitätsmaßes auf Basis der gemessenen Effekte der Anwendung einer Erfahrung. Dieses Validitätsmaß kann wiederum dafür verwendet werden, um eine Entscheidung automatisch zu treffen, ob eine Erfahrung automatisch angewendet wird oder ob sie erst nach Rückfrage bei bzw. Freigabe durch einen Menschen angewendet wird. Hierfür müssen entsprechende Schwellwerte gesetzt werden. Durch das Validitätsmaß und die Schwellwerte kann somit ein Self-Healing realisiert werden, dessen Automatisierungsgrad durch die Validitäts-Schwellwerte parametrisiert werden kann. Ein Defekterfahrungs-Fall besteht aus Beobachtungen, Ursache, Behebung und Erfolgskontrolle (erwartete Effekte). Die Erfolgskontrolle beschreibt hierbei, wie das Eintreten der erwarteten Effekte geprüft werden kann. Bild 5 zeigt ein Beispiel in der Darstellung als strukturierter Text, wie es vor Ort akquiriert werden konnte. Für das Reasoning ist eine Formalisierung nötig. Ob eine Online-Erfassung und Online-Änderung von Fällen machbar ist, hängt davon ab, ob die Erfassung und Änderung von Defekterfahrungen in formalisierter Form durch Werker, Produktionssteuerer oder Produktionsleiter erfolgen kann. Beobachtungen: 1.

Die automatische Sichtkontrolle erkennt auf einen Fließfehler

Ursache: „

Einspritzdruck bei Formgebung zu gering

Behebung: „

Einspritzdruck erhöhen

Kontrolle:

Beobachtungen: 1.

Die automatische Sichtkontrolle erkennt auf einen Fließfehler

2.

Die Oberfläche des Rohteiles ist matt

Ursache: „

Formgebungswerkzeug ist verschmutzt

Behebung: „

Formgebungswerkzeug reinigen

Kontrolle:

„

Fließfehlerkontrolle: OK

„

Fließfehlerkontrolle (Folgeteile): OK

„

Vgl. Fließlinie vorher/nachher: weniger ausgeprägte Fließlinie

„

Vergleich Mattigkeiten/Fließlinien: weniger matt, irrelevante Fließlinie

Bild 5: Beispiele für Defekterfahrungen

Anbindung an Sensorik und Aktorik der Produktionsanlage Die Anbindung an die Sensorik erfolgt unter Verwendung der im Projekt BridgeIT entwickelten Portalstruktur. Die Sensordaten sowie weitere produktionsbezogene Daten werden hier online in einer zentralen Datenbank abgelegt [8]. Der Defekterfahrungs-Reasoner kann damit auf sämtliche Daten über den aktuellen Anlagenzustand zugreifen. Allerdings sind die Sensordaten durchaus -3-

unterschiedlich aktuell. Während die Artikel- und Prozessdaten jederzeit verfügbar sind, muss für die Inspektion von Werkzeugen auf Totzeiten im Artikelstrom der Anlieferung zurückgegriffen werden, damit es nicht zur Beeinträchtigung der Taktzeit führt, da dies i.d.R. nicht akzeptiert würde. Somit müssen Zustandsdaten ggf. explizit von der Anlage angefordert werden. Das führt dazu, dass die Reihenfolge der Abfrage der Sensordaten so optimiert werden kann, dass möglichst unter Verwendung der fortlaufend aktualisierten Sensordaten entschieden wird und weitere Sensordaten in möglichst kostengünstiger und erfolgversprechender Reihenfolge angefragt werden. Für die Reihenfolge der Sensordatenabfrage zur Ermittlung der aktuellen Situation wird derzeit ein Verfahren auf Basis des Information-Gain in Kombination mit Informationsbeschaffungsaufwänden (Zeitdauer der Sensordatenbeschaffung und Verzögerung der Produktion in Kombination mit Höhe des Risikos der Produktion von Schlechtteilen) angestrebt. Zurzeit wird zur Anbindung der Aktorik an Handlungsvorschlägen für die Werker über die bereits vorhandenen HMIs gearbeitet, zukünftig soll zusätzlich der direkte Zugriff auf System- und Benutzervariablen der Anlagen- und Roboter-Steuerung via OPC [9] erfolgen.

Wissensakquisition –formalisierung

und

Zur Akquisition vorhandenen Erfahrungswissens müssen zunächst mögliche Datenquellen identifiziert und auf ihre Nutzbarkeit hin untersucht werden. Als sinnvolle Quellen wurden die in den Produktionsprozess aktuell eingebundenen Personen (d.h. Werker, Einrichter, Inbetriebnahmepersonal, Anlageningenieure, Produktionsleiter), sowie bereits formalisiert festgehaltene Ursachen-Wirkungs-Zusammenhänge erkannt. Letztere werden heute üblicherweise im Rahmen der Qualitätssicherung erstellt (Abnahmekatalog, FMEA3). Die Erfahrungen prozessbeteiligter Personen konnten initial nur über die Beobachtung ihrer Arbeitsprozesse und Nachfragen ihrer Handlungen abgeschöpft werden. Für diese Zwecke haben wir gute Erfahrungen damit gemacht, einen angehenden Maschinenbau-Ingenieur bzgl. der Wissensakquisition zu instruieren. Dieser hatte den Vorteil, dass er schon über das Vokabular der Domäne verfügte und damit die Erfahrungen leichter durch Beobachtung und Nachfragen akquirieren und der Sinnhaftigkeit hinterfragen konnte, als es einem Informatiker oder Knowledge-Engineer ohne solche Domänenkenntnis möglich wäre. Aus Produktionsläufen in 2 Monaten konnten hierbei mehr als 80 Defekterfahrungen als strukturierter Text akquiriert werden. Für die Formalisierung ist es hilfreich, wenn der Wissensakquisiteur bereits die spätere Formalisierung im Blick hat. 3

FMEA steht für „Failure Modes and Effects Analysis“, bzw. für „Fehlermöglichkeits- und Einflussanalyse“ (DIN 25448)

Die Formalisierung des Wissens erfolgt durch Wissensmanagement-Experten. Unter Berücksichtigung der Nähe der Erfahrungsdaten zu kognitiven Prozessen der beteiligten Erfahrungsgeber wird ein CBR-System aufgesetzt, das die Erfahrungen in Fällen organisiert, die im Wesentlichen prozessnahe Beobachtung-Ursache-Behebung-Kontrolle-Tupel abbilden. Bereits andersartig formalisiertes Wissen, wie z.B. aus der FMEA, wird entsprechend transformiert, zusätzliche Informationen wiederum erweitern die Formalisierung in der Fallbasis. So kann z.B. die Auftretenswahrscheinlichkeit ein Teil der Risikobewertung aus der FMEA - automatisiert festgehalten und ausgewertet werden.

Zusammenfassung, Ausblick

Status

und

Das im CheckMATE-Projekt entwickelte Self-HealingVerfahren auf Basis des Experience-Feedback-Loop mit prozessintegriertem Case-based-Reasoning unterstützt die Realisierung kleinster Qualitätsregelkreise. Als Erfahrungen werden hierbei so genannte Defekterfahrungen zur Erkennung von Fehlern oder entsprechenden Trends sowie Behebungs- und Kontroll-Maßnahmen verwendet. Hiermit soll ein Service-Roboters für Anlagen- und TeilInspektion und zum Stellen von Produktionsparametern gesteuert werden. Validitätsinformationen ermöglichen eine automatische Entscheidung, ob BehebungsMaßnahmen mit oder ohne Nachfrage beim Werker angewendet werden dürfen. Der Status der Entwicklungen ist wie folgt: Die Defekterfahrungen wurden in einem 2-monatigen Anlagebetrieb akquiriert. Auf dieser Basis wurde die Reasoning-Technolgie ausgewählt. Derzeit (Januar 2007) werden die Defekterfahrungen formalisiert und in einen ersten funktionstüchtigen Prototyp gefüttert. Eine Evaluation mit einer Maschine beim Anwendungspartner Freudenberg ist für 2007 geplant. Weiterhin stellt sich die Frage, ob und wie eine OnlineErfassung neuer Fälle in der Praxis möglich ist. Ob eine Formalisierung neuer Fälle bei einem bereits vorliegenden, hinreichend formalen Wissensmodell durch einen Maschinenbauer oder sogar einen Arbeiter (Werker) möglich ist, müssen weitere Studien zeigen.

Literatur [1] A. Aamodt and E. Plaza: Case-based reasoning: Foundational issues, methodological variations, and system approaches. AICom - Artificial Intelligence Communications, 7(1):39–59, March 1994. [2] Bergmann, R., Althoff, K.-D., Breen, S., Göker, M., Manago, M., Traphöner, R., and Wess, S.: Developing Industrial Case Based Reasoning Applications - The INRECA Methodology. LNAI 1612, 2nd edition. Springer Verlag, 2003. [3] Otto Föllinger, Frank Dörrscheidt, Manfred Klittich: Regelungstechnik. Einführung in die Methoden und ihre Anwendung. 8. überarbeitete Auflage. Hüthig Verlag, 2005.

-4-

[4] Jürgen Grotepaß. Vision Inspection Systems as Integral Elements for Continuous Improvements of Production Lines. EMVA, 3rd European Machine Vision Business Conference; Palermo; April 29-30, 2005. http://www.emva.org/ [5] Fraunhofer Gesellschaft. Studie Wissen und Information 2005. Fraunhofer IRB Verlag, 2006. [6] McKinsey. Analyse des in der Automobilzulieferindustrie erreichten Qualitätsstandards. SIS „Surface Inspection Summit, Aachen, 2003. [7] Markus Nick: Reducing the case acquisition and maintenance bottleneck with user-feedback-driven case base maintenance. In Proceedings of the Nineteenth International FLAIRS Conference, AAAI Press, 2006. [8] Nick, M.; Schneickert, S.; Grotepaß, J.; Hamfeld, H.; Rose, T.; Sander, T.; Stöhr, M.; Stumpe, W.; Winterberg, H.: Integration von Qualitätsdaten für Produktionsanlagen. In: Schaaf, M. (ed.), et al.; Universität Hildesheim: Lernen Wissensentdeckung - Adaptivität. Workshopwoche der GI-Fachgruppen/Arbeitskreise, LWA 2006. Hildesheim, 2006, pp. 202-208 [9] OPC Foundation. http://www.opceurope.org/