Von der Störungserkennung über die Diagnostik zur Wissensakquisition

Störungserkennung und -lokalisierung

Das Vorgehen der Diagnostik beginnt sowohl beim manuellen als auch beim automatischen Vorgehen mit dem Vorliegen einer Störung. Damit beginnt der Vorgang der Diagnostik mit dem Versagen einer Anlagenkomponente, welches in der Regel weitere Ausfälle entlang der Montage-Fortschrittsfolge initiiert.

Aufgabe der Störungserkennung im weiteren Sinne ist dann die Fusion der Steuerungsdaten und meint das Hinzuziehen der steuerungsinternen Datenquellen wie RC, NC etc., um anhand der weitaus umfangreicheren Standardüberwachungs- und Diagnosefunktionalitäten auf involvierte Symptome schließen zu können. Ein Online-Störungsmanagement-System hätte darauf aufbauend die Aufgabe, in einer vordefinierten zeitlichen Frequenz das BSDE nach neuen Stillstandsursachen, welche seit dem letzten Zugriff noch nicht behoben wurden, also denen vom BSDE noch kein Austrittsdatum und keine -uhrzeit zugewiesen wurden, abzufragen und auf diese in geeigneter Form hinzuweisen. Die Diagnose meint dann darüber hinaus das Zuweisen einer speziellen Ursache und Maßnahme unabhängig vom Parametrierungstext (Fehlermeldung) der einzelnen SPS-Bits zu genau einer Störung.

Für die Störungserkennung im Rahmen dieser Arbeit sind keine Standardmodule bekannt, da heutige BSDE-Systeme mit der Visualiserung der gestörten Station enden. Die Lokalisierung der Station im Netzwerk zuzüglich des Auslesens involvierter Symptome ist für diese Arbeit zu entwickeln.

Diagnostik im engeren Sinne

Mit dem Auslesen des Fehlerdokuments der lokalisierten Steuerung beginnt die Diagnose im engeren Sinne. Aufgrund der Unterscheidung zwischen manueller und automatischer Diagnose müssen weitere Unterscheidungen bezüglich des Vorgehens und somit der Konzeption der Unterstützungsumgebung gemacht werden. Sowohl die manuelle als auch die automatische Diagnose beruht auf der Tatsache, daß Erfahrungen aus der Vergangenheit akquiriert und später mittels der geeigneten Wissensrepräsentationstechnik zugänglich gemacht werden, um auf neue Störungen angewendet werden zu können. Dabei ist der Prozeß der Wissensmanipulation vor dem Hintergrund des fallbasierten und assoziativen Ansatzes aufgrund ihrer divergenten Methodik getrennt zu betrachten. Dennoch muß die Wissensrepräsentation einheitlich gestaltet werden, so daß Störungen, die beispielsweise mittels des fallbasierten Ansatzes aufgenommen wurden, auch über den assoziativen Ansatz angewendet werden können und umgekehrt.

Für die wissensbasierte Diagnostik sind auf dem Markt zwar unterschiedlichste Verfahren bekannt, die jedoch auf manuellen Ursache-Wirkungsassoziationen bzw. auf manuell erfaßten Symptomen basieren. Das automatisierte Anwenden der von Assoziationen auf digital erfaßte steuerungsinterne Symptome ist auf dem Markt nicht bekannt. Hieraus ergeben sich Entwicklungsbedarfe für das Aufbereiten und Gewichten von Symptomen, die Bildung abstrakter Störungsklassen und daraus resultierend auch für die Ähnlichkeitsbestimmung zwischen Störungen und für das Retrieval nach bekannten Störungen.

Reuse und Revise von Lösungen

Die Diagnose im engeren Sinn endete mit dem Retrieval, wenn gleiche Störungen gefunden werden und sich direkt auf den aktuellen Fall anwenden lassen. Tritt dieser Fall nicht ein, müssen dem Experten oder Instandhalter für den Reuse-Prozeß alle Vorschläge in adäquater Form präsentiert werden, so daß die Möglichkeit besteht, der Reihe nach jeden Fall anhand der Realität zu überprüfen und geeignet reagieren zu können. Dem Experten muß also für jeden Fall die zugehörige Fehlerbeschreibung und Maßnahmeninstruktion visualisiert werden. Es Stellt sich die Frage, wie das Wissen, also die vom System unterbreiteten Vorschläge, auf die aktuelle Problemstellung adaptiert werden kann, wenn keine gleichen, also direkt übertragbaren Fälle gefunden wurden. Bereits im Rahmen der Wissensmanipulation wurde das transformationale und derivationale Vorgehen in Abhängigkeit von der zu bearbeitenden Domäne unterschieden. Aufgrund der bis jetzt erläuterten Methode zur Ermittlung bekannter Störungen kommt für die hier zu behandelnde Domäne lediglich das transformationale Vorgehen, also das Adaptieren der Lösung des zurückgelieferten Falles auf die aktuelle Problemstellung, in Frage. Gemeint ist damit, daß der Experte auf Basis eines ähnlichen Vorschlages - vorausgesetzt, das aktuelle Problem konnte diagnostiziert werden - einen neuen Fall generieren und in der Wissensbasis archivieren kann.

Stellt sich die Frage, was mit Fällen geschieht, die sich trotz vorgeschlagener Lösungen nicht diagnostizieren, sich also mittels des transformationalen Vorgehens nicht adaptieren lassen. Hierfür beinhaltet das derivationale Vorgehen das Anpassen der Methode, mit welcher die Lösung des zurückgelieferten Falles ermittelt wurde, auf die aktuelle Problemstellung. Bis jetzt wurde davon ausgegangen, daß alle Störungen direkt von dem Betriebsmittel, also über das sogenannte KCP oder von einem dezentralen PC-Arbeitsplatz über das lokale Netzwerk (lokaler Arbeitsplatz) behandelt werden. Um die Methode zur Suche einer Lösung zu ändern, müßte eine Störung, die am KCP mit dem Wissen und den vorliegenden Informationen des Instandhalters nicht zu diagnostizieren wäre, abgelehnt und damit für eine Bearbeitung von einem anderen Arbeitsplatz freigegeben werden können. Es wäre dann systemseitig zu realisieren, daß sich beispielsweise ein remote Arbeitsplatz über das System dieser Störung annimmt und unter Hinzuziehung weiterer Detailinformationen aus Konstruktionsplänen, Aufbauplänen etc. die Diagnose übernimmt. Das System hält somit zum einen sämtliche Informationen über eine Störung in Form von Symptomen und Erfahrungen bereit und zum anderen fungiert es als Kommunikationsschnittstelle zwischen Instandhalter vor Ort und dem Spezialisten am remote Arbeitsplatz, der mittels weiterer Informationen andere Lösungen ableiten und zur Verfügung stellen kann (Abb. 33).

Aufgrund des divergenten Beschreibungsniveaus der Experten muß die Situation des Revise, des Reparierens von Lösungen in Betracht gezogen werden. Diese Situation tritt dann auf, wenn ein Fall die gleichen Symptome aufweist und direkt übertragbar ist, dennoch von seiten der formalen Beschreibung geändert werden muß. Sollte also eine Fehlerbeschreibung zu speziell formuliert worden sein, wie beispielsweise Schweißperle auf Sensor und im aktuellen Fall handelt es sich um Staubpartikel, die den gleichen Effekt hervorrufen, so müßte die Beschreibung beispielsweise in Sensor verschmutzt geändert werden. Die neue Beschreibung wäre dann umfassender formuliert, so daß kein neuer Fall generiert, sondern lediglich der Zähler inkrementieren würde (Abb. 33). Es steht nicht zu befürchten, daß der Experte die Fehlerbeschreibung nicht mit dem aktuellen Fall in Zusammenhang bringen würde, da er ja über dessen Beschreibung den Fall diagnostizieren konnte und somit lediglich an dessen Formulierung Anstoß nehmen dürfte.

Wissensakquisition

Die Wissensakquisition kann nur im Zusammenhang mit der Wissensmanipulation und repräsentation betrachtet werden. Das Anwenden einer Lösung im vorangegangenen schließt in jedem Fall mit der Akquisition des daraus gewonnenen Wissens. Gerade die Aufnahme neuen Wissens entscheidet über die Funktionstüchtigkeit des gesamten Systems, da die spätere Methode der Störungsvermeidung auf Analysen der Wissensbasis beruht und somit Fälle, die beispielsweise unterschieden wurden, obwohl derselbe gemeint war bzw. umgekehrt, ein Fall wurde inkrementiert, obwohl unterschiedliche gemeint waren, eine falsche Berechnungsgrundlage bilden würden. Über eine falsche Zuordnung hinaus muß somit systemseitig dafür gesorgt werden, daß keine Störung in irgendeiner Form der Wissensakquisition entgehen kann. Die generelle Voraussetzung dafür ist, daß jede Störung über das System analysiert werden muß bzw., sollte dies nicht der Fall sein, deren Nichterfüllung registriert wird, um vor Auswertungen den Experten darauf hinweisen zu können.

Bereits im Kapitel (3.2.1.2) wurde zwar zwischen dem automatischen und direkten Wissenserwerb unterschieden, dennoch können beide Ansätze in dieser Arbeit nicht losgelöst voneinander betrachtet werden. Der Grund dafür liegt in der automatischen Generierung der Symptome, die als fest vorgegeben zu betrachten sind und der gleichzeitigen manuellen Selektion vorgeschlagener Fälle bzw. der manuellen Aufnahme komplett neuer Fälle. Das System hat also für die Aufnahme der Symptome und Häufigkeiten den automatischen und für die Integration der Fehlermeldung und Maßnahmeninstruktion den direkten Ansatz auf Basis der Implementierung zu unterstützen.

Für den direkten Ansatz der Wissensakquisition sind bereits unterschiedlichste Methoden bekannt. Für die automatische Akquisition hingegen müssen einige zusätzliche Besonderheiten berücksichtigt werden, welche vor dem Hintergrund automatisierter Symptomerfassung zu entwickeln sind.