Wissensbasierte Strörungsbehebung an hoch komplexen Montagesystemen

Wissensabsierte Störungsbehebung

Im Anschluß an das Lokalisieren einer defekten Maschine, dem Abgreifen und Konvertieren der steuerungsinternen Daten (Symptome), beginnt die eigentliche Störungsbehebung im Dialog mit dem Diagnostiker.

1. Die Lokalisierung einer defekten Station ist mit der Prozeßüberwachung bereits auf Bit-Ebene abgeschlossen. Die Rückkopplung zum Betriebsmittel bzw. zu einem auf diesem laufenden Software-Tool zum Auslesen der steuerungsinternen Signale muß über konventionelle Netzwerknamen initiiert werden, da die Bit-Belegung seitens der SPSen nur im BSDE-System bekannt ist. Dementsprechend müssen die Daten des BSDE-Systems in Analogie zu den Symptomen allgemeingültig konvertiert werden.

An dieser Stelle sollte jedoch nicht mit einer Zuordnungstabelle, sondern mit einem Modell und entsprechend modellierbaren Attributen gearbeitet werden, da die Namensgebung nicht statisch ist. Namensänderungen müssen sowohl eingegeben werden, wenn sich am BSDE-System Änderungen ergeben, als auch dann, wenn sich Änderungen im Netzwerk oder an dem Betriebsmittel selber ergeben. Gleichzeitig wird im Rahmen der Störungsvermeidung ohnehin auf diesen zurückgegriffen werden müssen. Im Modeller müssen folglich die Attribute Netzwerk- und BSDE-Name eines jeden Betriebsmittels geführt werden.

Die zu installierenden Module müssen bis hierhin folgende Aufgaben erfüllen: im Fall eines nicht zu ignorierenden Signals seitens des BSDE-Systems muß von einem zentralen Servermodul dies erkannt, der BSDE-Name in den Netzwerknamen konvertiert und das auf dem Betriebsmittel laufende Modul angestoßen werden. Dieses entnimmt der Steuerungsschnittstelle die internen Signale, übersetzt diese in die allgemeingültigen Beschreibungen und stellt sie dem Störungsmanagement als Symptome zur Verfügung.

2. Grundsätzlich sind mit den verfügbaren Symptomen alle Punkte für die sich anschließende Diagnose erfüllt. Der softwareseitig zu unterstützende Prozeß der Störungsbehebung beginnt mit der Interaktion zwischen Instandhalter und der Wissensbasis. Hierfür sollte sowohl das Modul am Maschinendisplay als auch eine im Büro verfügbare Anwendung alle Funktionalitäten zur Verfügung stellen, da die Diagnostik sowohl vor Ort als auch remote eingeleitet werden können muß. Beide Möglichkeiten sollten Vorteile für verschiedenen Situationen bieten.

Die Praxis zeigt, daß die Diagnose und Behebung einer Störung in der Regel vor Ort an der Maschine, vom Anlagenführer oder in schwereren Fällen von der Instandhaltung (Elektriker, Mechaniker) vorgenommen wird. In Ausnahmefällen ist es jedoch unumgänglich, Diagnosen auch von weiterführenden Spezialisten (Roboter-, Interbusspezialist etc.) remote vornehmen zu lassen. Ab welchem Schweregrad ein Spezialist hinzugezogen werden muß, wird über die individuelle Meldekette der Abteilung oder Firma festgelegt. Über diese Vorgehensweise hinaus, setzt der Dialog am Maschinendisplay voraus, daß notwendige Eingaben sofort getätigt werden, um das Display für Reparaturmaßnahmen oder neue Störungen schnellstmöglich frei zu geben. Die Eingaben sofort zu erledigen ist jedoch nur dann praktikabel, wenn der Instandhalter Diagnoseunterstützung braucht oder genug Zeit ist, um sich mit der Systempflege zu beschäftigen. Andernfalls sollten die Eingaben beispielsweise am Schichtende vorgenommen werden können. Für letzteren Fall braucht der Instandhalter zusätzliche Informationen, um sich den Vorgang erneut vergegenwärtigen zu können.

3. Die Rückkopplung an das Störungsmanagement-System muß dementsprechend die Rückmeldung der ausgelesenen Symptome beinhalten, anhand derer das Retrieval innerhalb der Wissensbasis vollzogen werden soll, sowie die Rückmeldung des Suchergebnisses an das Maschinendisplay und der spätere Zugriff auf alle behandelten Daten. Gleichzeitig muß die Performance des Retrieval so hoch sein, daß für die Reparatur keine Wartezeiten auf die Ergebnisse entstehen. Darüber hinaus ist es zwingend erforderlich, alle in Frage kommenden Vorschläge zu finden und anzubieten, um keine Redundanzen ins System zu bringen und die Auftrittshäufigkeiten nicht zu verfälschen, da anhand dieser die Intervalle für Präventionen errechnet werden sollen.

4. Für eine schnelle Handhabung und damit zukünftige Akzeptanz des Störungsmanagement-Systems ist es weiterhin erforderlich, die Vorschläge entsprechend ihrer Wahrscheinlichkeit zu sortieren und so zu präsentieren, daß zum einen eine schnelle Entscheidungsfindung und zum anderen schnelles Auswählen unterstützt wird. Auch wenn die Symptome noch so detailliert erfaßt werden, werden immer mehrere Störungen mit gleicher Symptomkonstellation auftreten. Dementsprechend wird die Entscheidungsfindung um so komfortabler unterstützt, je weniger Störungen für ein und dieselbe Symptomkonstellation existieren oder je mehr manuelle Filterkriterien existieren. Das System muß folglich in der Lage sein, weitere manuelle Eingrenzungen vorzunehmen.

5. Mit Eingabe der Fehlerbeschreibung und Maßnahme für eine neue, noch nie aufgetretene Störung oder der Bestätigung des erneuten Auftretens einer bekannten Störung und eventuelles Ergänzen der Maßnahmen ist die Eingabe seitens der Instandhaltung beendet. Vom System ist die Manipulation der statistischen Daten, auf die im nächsten Abschnitt noch zurückzukommen sein wird, automatisch zu vollziehen. Als letzter Schritt sollte das Störungsmanagement-System zulassen, daß die Eingaben für neue Störungen von einem Administrator bzw. Verantwortlichen bestätigt oder geändert werden können. Dies kann zum einen dann notwendig sein, wenn die Beschreibung mißverständlich ist, der Instandhalter eine Störung als Neu aufgenommen hat, obwohl diese einer anderen so ähnlich ist, daß sie dieser zugeordnet werden soll, oder aber, wenn die Beschreibung zu abstrakt ist.

Sollten sich entsprechend 4. zu viele Lösungsvorschläge innerhalb einer Symptomkonstellation ansammeln, muß der Administrator weitere manuelle Filterkriterien anlegen. Diese sollten zum einen frei wählbar sein, dennoch aber die Lösungsmenge in möglichst gleich große Untermengen gliedern, für den Instandhalter leicht verständlich sein, also in gebräuchlichem Vokabular und für praktische Situationen schnell zu unterscheiden. Neue Störungen, die nach einer derartigen Gliederung auftreten, müssen entsprechend gewählter Logik eingeordnet werden. Diese Tätigkeit sollte vom Administrator vorgenommen werden, um zum einen die Konsistenz der Logik zu gewährleisten und zum anderen einen permanenten Wartungsprozeß zu erzwingen.