-
Hintergrund
-
Die
vorliegende Erfindung bezieht sich allgemein auf das Gebiet der
Wartung komplexer Systeme und konkreter auf eine Technik zum Einbeziehen von
Wartungsdaten in eine Wissensbasis, die eine verbesserte Formulierung
von Wartungsempfehlungen, eine Priorisierung von Wartungsempfehlungen und
eine Erzeugung und Verarbeitung von Systemdaten durch eine Systemmomentaufnahme
ermöglicht,
wo es angebracht ist.
-
Eine
Reihe von Techniken sind entwickelt worden, um komplexen Systemen
eine Fernwartung und Wartung vor Ort zur Verfügung zu stellen. Wo Systeme
nicht mit einer Fernverbindung ausgestattet sind, haben traditionelle
Techniken bestimmte Selbstbedienungsverfahren beinhaltet. Diese
sind typischerweise in gewisser Hinsicht begrenzt und können letzten
Endes die Inspektion durch einen qualifizierten Wartungstechniker
erfordern, der Fehlfunktionen und unregelmäßige Zustände auswerten, eine Wartung
empfehlen und bestimmte Wartungsmaßnahmen durchführen kann,
wie z.B. den Austausch von Teilen, eine Neukonfiguration usw..
-
Für die Fernwartung
sind bestimmte weitere Techniken entwickelt worden. Auf dem Gebiet
der medizinischen Diagnostik können
z.B. bestimmte Systeme, insbesondere komplexere und technisiertere
Systeme (z.B. medizinische diagnostische Bildgebungsgeräte) für eine Fernverbindung
ausgerüstet sein.
Diese Systeme ermöglichen
es, dass Anforderungen einer Betriebswartung entweder direkt oder über ein
koordiniertes Mitteilungsverfahren an einen entfernten Wartungsdienstanbieter
gesendet werden. Bei bestimmten Techniken kann der entfernte Anbieter
Anforderungen automatisch verarbeiten, wie z.B. die Anforderung
in eine Bedienungswarteschlange einreihen und Mitteilungen zurück an den ursprünglichen
Anforderer der Wartung senden. Die gegenwärtige Technologie auf diesem
Gebiet verlässt
sich jedoch allgemein darauf, dass sich letzten Endes ein entfernt
von dem Wartungssystem befindlicher Wartungsingenieur der Wartungsanforderung zuwendet.
Auf der Grundlage des Wissens des Ingenieurs und dem Ingenieur zugänglicher
Materialien können
Wartungsempfehlungen abgegeben werden, kann ein Wartungstechniker
geschickt werden oder können
andere Abläufe
folgen.
-
Während solche
Techniken zur Bereitstellung von Wartungsmaßnahmen und insbesondere der
Fernwartung nützlich
sind, sind sie nicht ohne Nachteile. Vorhandene, hoch entwickelte
Wartungsverfahren verlassen sich z.B. häufig letzten Endes auf das
Wissen und die Erfahrung des Wartungsingenieurs oder eines anderen
Technikers, der sich den Wartungsbelangen zuwendet. Gegenwärtig sind
allgemein keine Systeme verfügbar,
die Wartungsanforderungen durch Zugriff auf zusätzliche Informationen automatisch
handhaben können,
um einen weiten Bereich von Daten nutzbar zu machen, wie er für den Wartungsdienstanbieter
verfügbar
wird.
-
In ähnlicher
Weise ist eine Priorisierung von Wartungsanforderungen und -reaktionen
allgemein erheblich rückwirkend.
In dem Maße,
in dem in der Fachwelt irgendeine Priori sierung ausgeführt wird, geschieht
dies allgemein auf der Grundlage einer „Wer zuerst kommt, mahlt zuerst"-Verarbeitung („First
come, first served")
mit geringer oder keiner Neuordnung nach Priorität in der Abhängigkeit
von relevanten Faktoren. Eine beliebige Neupriorisierung kann z.B.
einfach auf eine Dringlichkeit gestützt sein, die dem Wartungsdienstanbieter
von dem Wartungsanforderer mitgeteilt wird, wie z.B. telefonisch,
durch dringende Mitteilungen usw..
-
Schließlich schaffen
die gegenwärtigen Techniken
nicht allgemein eine Basis für
eine vollständige
Auswertung des Wartungsbedarfs. Bestimmte Systeme ermöglichen
die Erfassung von Fehlerprotokollen, bestimmten Systemdateien usw., liefern
aber allgemein kein vollständigeres
Bild in Form einer Momentaufnahme („Schnappschuss"). Konkreter ermöglichen
die gegenwärtigen
Techniken allgemein keine Auswertung einer Gerätekonfiguration, die eine Grundursache
für ein
wartungsbedürftiges
Ereignis sein kann.
-
Daher
besteht Bedarf an weiteren Verbesserungen auf dem Gebiet der Systemwartung
und insbesondere der Fernwartung komplexer Systeme.
-
Kurze Beschreibung
-
Die
vorliegende Erfindung stellt eine neuartige Technik zum Warten von
Systemen zur Verfügung,
die dazu eingerichtet ist, auf solche Bedürfnisse einzugehen. Die Technik
kann in einen weiten Bereich von Umgebungen angewandt werden, ist
aber insbesondere für
die Fernwartung von komplexen Systemen durch einen entfernten Wartungsdienstanbieter
gut geeignet. Spezielle interessierende Anwendungsgebiete der Techniken können medizinische,
diagnostische Geräte
und andere Systeme enthalten, wo die Zuverlässigkeit und die verfügbare Betriebszeit
entscheidend sind. In solchen Systemen kann eine proaktive Fernwartung
von zahlreichen Systemfaktoren der effizienteste Weg sein, die Produktivität des Systems
aufrecht zu erhalten, und die vorliegenden Techniken bieten Werkzeuge,
um sich Wartungsanforderungen auf dieser Grundlage zuzuwenden.
-
Ein
wartungsbedürftiges
Ereignis oder ein wartungsbedürftiger
Zustand in einem gewarteten System können unter Bezugnahme auf einen
Indikator, wie z.B. einen Leistungsparameter, einen Betriebsparameter,
ein Fehlerprotokoll usw. erkannt werden. Als Reaktion kann automatisch
eine Wartungsanforderung erzeugt werden. Die Wartungsanforderung
teilt dem Wartungsdienstanbieter den Wartungsbedarf an einem Zustand,
typischerweise einem unregelmäßigen Zustand
in dem System tatsächlich
mit. Gestützt
auf eine Anforderung kann der Wartungsdienstanbieter auf eine integrierte
Wartungswissensbasis (ISKB) zugreifen, in der Wartungsdaten, Priorisierungsdaten,
Wartungsempfehlungsdaten usw. gespeichert sind.
-
Ebenfalls
als Reaktion auf Wartungsanforderungen kann von dem Wartungsdienstanbieter
eine Priorisierung vorgenommen werden. Eine solche Priorisierung
kann verschiedene Reaktionen auf den wartungsbedürftigen Zustand in einem einzigen
System wirksam nach Vorrangigkeit ordnen, kann aber auch eine Priorisierung
von Wartungsreaktionen zwischen Systemen enthalten, wie z.B., wenn
der Wartungsdienstanbieter eine Anzahl von verschiedenen Systemen
bedient. Die Priorisierung kann auf Priorisierungswerte gestützt sein,
und diese können
ebenfalls in einer ISKB gespeichert sein.
-
Die
vorliegenden Techniken ermöglichen auch
ein Erfassen einer Systemmomentaufnahme beim Auftreten eines wartungsbedürftigen
Zustandes oder Ereignisses. Die Systemmomentaufnahme kann eine Reihe
von Systemdaten enthalten, enthält aber
in vorteilhafter Weise Hardwarekonfigurationsdaten, die mit anderen
Daten von dem System korreliert und zur Bewertung des wartungsbedürftigen
Zustands oder Ereignisses verwendet werden können. In den gegenwärtig in
Betracht gezogenen Ausführungsformen
liefern die Hardwarekonfigurationsdaten eine Angabe über in dem
System installierte Komponenten sowie Peripheriegeräte und andere Hardware,
die die Grundursache des wartungsbedürftigen Zustandes oder Ereignisses
oder der Fehlfunktion sein könnten.
-
Die
vorliegenden Techniken ermöglichen auch
die Erzeugung und Benutzung einer ISKB. Die ISKB kann Daten aus
einem weiten Bereich von Quellen sammeln, zusammenfassen und korrelieren und
wird sich allgemein auf gewartete Systeme von einem oder mehreren
Typen und Konfigurationen beziehen. Die ISKB wird typischerweise
Systeme kennzeichnende Daten, bekannte unregelmäßige Zustände oder wartungsbedürftige Ereignisse
kennzeichnende Daten, möglichen
Reaktionen und Empfehlungen zur Wartung der Systeme bezeichnende
Daten usw. enthalten. Die ISKB kann auch Priorisierungsinformationen
enthalten, die verwendet werden, um sowohl für Einzelsysteme als auch für eine Reihe
von Systemen und Situationen Wartungsempfehlungen nach Vorrangigkeit
zu ordnen. Wie oben angemerkt kann die ISKB zum automatischen Reagieren
auf Wartungsanforderungen und zum Ordnen von Reaktionen auf Wartungsanforderungen
nach Priorität
verwendet werden.
-
Zeichnungen
-
Diese
und weitere Merkmale, Aspekte und Vorteile der vorliegenden Erfindung
werden besser verstanden, wenn die folgende detaillierte Beschreibung
unter Bezug auf die beigefügten
Zeichnungen gelesen wird, in denen die gleichen Bezugszeichen die
gleichen Elemente bezeichnen:
-
1 ist
eine schematische Übersicht über ein
Wartungssystem, das ein ISKB-Erzeugungssystem und ein ISKB-gestütztes Wartungssystem
gemäß Aspekten
der vorliegenden Vorgehensweise enthält;
-
2 ist
ein Flussdiagramm, das eine beispielhafte Logik bei der Erzeugung
der ISKB darstellt;
-
3 ist ein Flussdiagramm, das eine beispielhafte
Logik beim Verarbeiten von Wartungsanforderungen darstellt;
-
4 ist
eine schematische Darstellung bestimmter Typen von Faktoren, die
beim Erstellen einer Priorisierung zwischen Wartungsanforderungen und
Empfehlungen oder Reaktionen, die auf solche Anforderungen gegeben
bzw. vorgenommen werden können,
berücksichtigt
werden können;
-
5 ist
ein Flussdiagramm, das eine Verarbeitung und Priorisierung von Wartungsanforderungen
und -empfehlungen darstellt;
-
6 ist
eine schematische Darstellung einer bestimmten Logik, die beim Aktualisieren
einer ISKB in Abhängigkeit
von bereitgestellter Wartung nützlich
ist;
-
7 ist
eine schematische Darstellung von Faktoren und Komponenten, die
gemäß Aspekten der
vorliegenden Vorgehensweise in einer Systemmomentaufnahme enthalten
sein können;
und
-
8 ist
ein Flussdiagramm, das einen beispielhaften Arbeitsablauf darstellt,
der zum Erfassen der Systemmomentaufnahme zur Berücksichtigung mit
einer Wartungsanforderung oder einer Empfehlung einer Wartung als
Reaktion auf eine solche Anforderung verwendet wird.
-
Detaillierte Beschreibung
-
Nun
den Zeichnungen gewandt und zuerst unter Bezug auf 1:
Ein System 10 zur Wartung komplexer Systeme, insbesondere
durch eine Fernverbindung zwischen den gewarteten Systemen und einem
Wartungsdienstanbieter, ist schematisch dargestellt. Wie von Fachleuten
erkannt wird, können solche
komplexen Systeme von einer Vielzahl von Arten sein, und zahlreiche
derartige Systeme können durch
die vorliegende Technik gewartet werden. In einer beispielhaften
praktischen Umsetzung könnten die
gewarteten Systeme z.B. medizinische diagnostische Geräte enthalten,
die in Einrichtungen, Kliniken, Krankenhäusern und dergleichen angeordnet
sein können.
Solche Geräte
können
von Ferne gewartet werden, indem eine Vernetzung direkt mit dem
System oder über
ein Zwischenelement, wie z.B. ein Datenmanagementsystem in der Einrichtung
oder durch einen dazwischen liegenden Datenaustauschanbieter hergestellt
wird. Der dazwischen liegende Datenaustauschanbieter kann z.B. Wartungsanforderungen,
Systemdaten, Mitteilungen usw. speichern und diese Daten zu dem
Wartungsdienst anbieter übertragen,
der letzten Endes dafür
verantwortlich ist, den Systemen die tatsächliche Wartung zur Verfügung zu stellen.
Der Wartungsdienstanbieter kann ein solches Zwischenelement auch
zum Reagieren auf die Wartungsanforderungen verwenden.
-
Es
sollte erkannt werden, dass der Begriff „Wartungsanforderung", wenn er hierin
verwendet wird, und die Reaktionen auf solche Anforderungen eine
operative Wartung von Systemen als Reaktion auf unregelmäßige Zustände, Fehlfunktionen
und dergleichen betreffen. In einem allgemeinen Sinne kann auf bestimmten
Gebieten eine „Anforderung" von Daten als eine
Wartungsanforderung bezeichnet werden. Eine solche Anforderung von
Daten kann in einem allgemeinen Sinne Anforderungen von Webseiten,
Informationen, Bilddateien usw. enthalten. Diese Anforderungen werden
in dem vorliegenden Zusammenhang jedoch nicht als „Wartungsanforderungen" angesehen, weil
sie sich nicht unregelmäßigen Zuständen und
Ereignissen oder Fehlfunktionen oder der Bewertung oder Reparatur
solcher Zustände
und Ereignisse zuwenden.
-
In
der Darstellung aus 1 kann in Betracht gezogen werden,
dass das System 10 zwei in gewisser Weise separate, aber
voneinander abhängige
Systeme enthält,
die ein ISKB-System 12 und eine
ISKB-gestütztes
Wartungssystem 14 enthalten. Obwohl sich nicht alle Merkmale
der vorliegenden Vorgehensweisen notwendigerweise auf die Erzeugung
einer ISKB oder auf eine Bezugnahme auf diese stützen, ist die ISKB beim Liefern
von Wartungsempfehlungen, einer Priorisierung und anderen hierin
beschriebenen Merkmalen in hohem Maße nützlich. Das ISKB-System 12 enthält ein ISKB-Erzeugungssystem 16,
das sich auf eine Reihe von Quellen und Daten stützt, die sich auf die Wartung
des gewarteten Systems beziehen. Wie von Fachleuten erkannt wird
und wie es unten genauer beschreiben ist, enthält das ISKB-Erzeugungssystem 16 typischerweise
einen oder mehrere programmierte Computer, die zum Empfangen der
benötigten
Daten oder zum Zugreifen auf diese und zum Verarbeiten der Daten zum
Herstellen von Korrelationen, Verbindungen und Beziehungen zwischen
den Daten in der Lage sind, die zum Bereitstellen der unten beschriebenen
Wartung verwendet werden. Wo es angebracht ist kann das ISKB-Erzeugungssystem
einen Einzelcomputer, der sich auf Datenbanken stützen kann,
die die notwendigen Daten für
die ISKB enthalten, oder mehrere Computer mit einer koordinierten
Verarbeitung enthalten. Es muss jedoch nicht auf alle Daten, die
in der ISKB enthalten sind, über
eine vorher erstellte Datenbank oder Bezugsquelle zugegriffen werden. Bestimmte
Daten können
während
der Erzeugung der ISKB manuell eingegeben und während der Erzeugung der ISKB
strukturiert und analysiert werden, wie es unten beschrieben ist.
-
Das
ISKB-Erzeugungssystem 16 wird sich allgemein auf Systemdaten,
wie sie in 1 mit dem Bezugszeichen 18 bezeichnet
sind, sowie auf Problemlösungsdaten 20,
relevante Instandhaltungsdaten 22, Indikatordaten 24 usw.
stützen.
Allgemein können
die Systemdaten 18 verschiedene Typen von Systemen und
ihre bekannten Herstellungsinformationen (z.B. Herstellungsort,
Herstellungsdatum, Seriennummern, laufende Nummern, Komponentenausfälle etc.)
bezeichnen.
-
Die
Lösungsdaten 20 können eine
Reihe von erkannten Problemen und Lösungen enthalten, die für die verschiedenen
Systeme bekannt sind. Die Lösungsdaten 20 können z.B.
bekannte „Fixes" für Probleme,
die bei der Herstellung oder ur sprünglichen Lieferung in Systemen
erkannt worden sind, sowie für
anschließend,
wie z.B. durch Wartungserfahrung, Wartungsinspektionen am Einsatzort
usw., identifizierte Probleme und Lösungen bezeichnen. Die Lösungsdaten
können
Hardwarekonfigurationslösungen,
Softwarekonfigurationslösungen,
empfohlene Austauschmaßnahmen
von Komponenten und im Einsatz austauschbaren Einheiten usw. enthalten.
-
In ähnlicher
Weise werden die Instandhaltungsdaten 22 typischerweise
Informationen enthalten, die sich auf die eingerichteten Instandhaltungsverfahren
beziehen, die für
bestimmte gewartete System ausgeführt oder empfohlen werden können. Die
Instandhaltungsdaten 22 brauchen sich nicht auf einzelne
Systeme oder Benutzer zu beziehen, wenn solche Informationen später beim
Erhalt einer Wartungsanforderung von den Systemen bezogen werden
können.
Wo es angebracht ist, können
solche systemspezifischen Informationen jedoch in der ISKB enthalten
sein.
-
Die
Indikatordaten 24 werden typischerweise beobachtbare oder
erkennbare Indikatoren für
mögliche
Fehlfunktionen, Ausfälle
oder bevorstehende wartungsbedürftige
Zustände
oder Ereignisse des Systems enthalten. Wo es möglich ist, werden solche Indikatordaten
ein Unterscheiden verschiedener Typen wartungsbedürftiger
Ereignisse, wie zwischen Komponenten, Teilsystemen und endgültiger Grundursachen
für die
wartungsbedürftigen
Ereignisse und Zustände
ermöglichen.
Wiederum werden die Indikatordaten 24 typischerweise für die verschiedenen
gewarteten System mit einzelnen Systemtypen, Beschreibungen, Definitionen,
Identifizierungen und dergleichen verbunden oder mit diesen korrelierbar sein.
-
Es
sollte erkannt werden, dass die Ausdrücke „Indikator" oder „Indikatordaten", wenn sie hierin verwendet
werden, jede beliebige Art von Hinweis auf einen möglicherweise
wartungsbedürftigen
Zustand bedeuten. Die Indikatoren können Parameter (z.B. Ströme, Spannungen,
verschiedene Signale), Kombinationen von Parametern usw. sein. In
bestimmten Systemen können
Indikatoren durch Überwachungs-
und Steuerungsalgorithmen, Trending-Algorithmen und dergleichen
bezeichnet, erzeugt oder wieder erkannt werden. In ähnlicher
Weise werden die wartungsbedürftigen
Zustände
typischerweise einige Arten von Fehlfunktionen des Systems enthalten.
Weitere Zustände
können
jedoch wie hierin beschrieben erkannt werden und zu einem Arbeitsablauf
führen,
die Zustände
enthalten, die verschiedene Verfolgungs-, Instandhaltungs- und sogar
Marketingfunktionen einleiten.
-
Zusätzlich zu
den verschiedenen Typen von Daten, auf die sich das ISKB-Erzeugungssystem 16 stützt, können verschiedene
Analyseroutinen 26 verwendet werden. Die Analyseroutinen
können
in Code einbezogen sein, der das ISKB-Erzeugungssystem bildet, oder
können,
wie es erforderlich ist, mit dem Systemcode verlinkt sein oder sich
auf diesen stützen.
Im Wege eines Beispiels können
die Routinen die Identifizierung, Analyse, Strukturierung, Indexierung,
Klassifizierung und andere unten beschriebene Vorgänge zulassen.
Wo auf Daten von unstrukturierten, halb strukturierten oder teilweise
strukturierten Datensätzen
zugegriffen wird, können
die Routinen z.B. aufgerufen werden, um die für eine Analyse und Reaktion
auf Wartungsanforderungen verwendeten aufgezeichneten Daten zu strukturieren.
Die Analyseroutinen können
auch eine Korrelation von Daten innerhalb der verschiedenen Aufzeichnungen,
auf die das ISKB-Erzeugungssystem 16 zugreift, und zwischen diesen
zulassen, insbesondere zwischen den Systemdaten, den Lösungsdaten,
den Instandhaltungsdaten und den Indikatordaten. Die ISKB wird z.B.
vorzugsweise Korrelationen zwischen den verschiedenen Typen von
Systemen, Serien oder Generationen von Systemen, bekannten Problemen
und Problemindikatoren für
die Systeme, bekannten Reaktionen auf die Probleme oder wartungsbedürftigen Zustände und
bekannte oder empfohlene Instandhaltungsmaßnahmen für das System enthalten.
-
Es
sollte beachtet werden, dass das ISKB-Erzeugungssystem 16,
wie es unten genauer beschrieben ist, auch eine Priorisierung von
Reaktionen auf einzelne bekannte und erkennbare wartungsbedürftige Ereignisse
und Zustände
erstellen kann. Bestimmte Indikatoren können z.B. zu der Schlussfolgerung
führen,
dass ein mehr oder weniger schwerwiegender Zustand in einem System
entstanden sein kann oder dabei sein kann zu entstehen. In Abhängigkeit
von solchen Indikatoren und bekannten Verläufen der Ausgaben, die von
solchen Problemen geliefert werden, können für die verschiedenen Indikatoren,
wartungsbedürftigen
Zustände und
Ereignisse, empfohlenen Reaktionen usw. Priorisierungswerte festgelegt
werden. Verfahren zum Erstellen einer solchen Priorisierung können manuell sein,
würden
aber in einer gegenwärtig
in Betracht gezogenen Ausführungsform
durch Analyseroutinen, auf die das ISKB-Erzeugungssystem 16 während der Erstellung
der ISKB zugreift, automatisiert oder halbautomatisiert sein.
-
In
Abhängigkeit
von den Daten, auf die das Erzeugungssystem 16 zugreift,
und von den verwendeten Routinen wird das ISKB-Erzeugungssystem 16 die
ISKB erzeugen, wie sie allgemein mit dem Bezugszeichen 28 bezeichnet
ist. Wie von Fachleuten erkannt wird, wird die ISKB selbst typischerweise
zugehörige Daten
in einer oder mehreren Datenbanken enthalten, die an einem permanenten
Speicherplatz oder mehr als einen Platz gespeichert würden. In
der gegenwärtig
in Betracht gezogenen Ausführungsform
befindet sich die ISKB auf einer einzigen Speichereinrichtung, wobei
natürlich
auch mehrere verbundene Speichereinrichtungen verwendet werden können. Darüber hinaus
sind der ISKB Schnittstellen zugeordnet, die es ermöglichen,
dass zur Bewertung, Überprüfung, Änderung
und Mitteilung auf die gespeicherten Daten, Priorisierungen und
weitere Merkmale der ISKB zugegriffen wird. In ähnlicher Weise können Schnittstellen
zum Übermitteln
von Informationen im Zusammenhang mit wartungsbedürftigen
Ereignissen oder Zuständen
an die ISKB durch automatische und/oder manuelle Mittel vorgesehen sein.
Eine automatische Eingabe und Bearbeitung von Wartungsanforderungen
ist unten genauer beschrieben.
-
Wie
es in 1 ferner dargestellt ist, bildet ein Wartungsreaktionssystem 30 einen
Teil des ISKB-gestützten
Wartungssystems 14. Das Wartungsreaktionssystem 30 wird
typischerweise einen oder mehrere Wartungscomputer enthalten, die
sich auf die Informationen in der ISKB stützen und Wartungsanforderungen
von wartungsbedürftigen
Systemen handhaben können.
Wo mehrere Wartungszentren vorhanden sind, z.B. um geographisch
getrennte System zu bedienen, kann das Wartungsreaktionssystem 30 eine
Reihe von Computern enthalten, die mit der ISKB 28 verbunden
oder verbindbar sind und miteinander verbunden sind, wo es angebracht
ist. Wie es unten genauer beschrieben ist, ist das Wartungsreaktionssystem 30 dazu
eingerichtet, Wartungsanforderungen zu empfangen, um sich auf Systeminformationen
und ISKB-Daten zu stützen,
und auf Wartungsanforderungen zu regieren oder Reaktionen zu empfehlen.
-
Allgemein
können
Wartungsanforderungen von einer beliebigen geeigneten Quelle stammen.
In einer gegenwärtig
in Betracht gezogenen Ausführungsform
können
die Anforderungen jedoch von einem Bediener oder einem Bedienersystem,
wie es mit dem Bezugszeichen 32 bezeichnet ist, oder durch einen
Anbieter erzeugt werden, wie es mit dem Bezugszeichen 34 bezeichnet
ist. Wie in der gegenwärtig
in Betracht gezogenen Ausführungsform
kann eine Bedienerwartungsanforderung 32 ihrerseits durch
ein wartungsbedürftiges
System nach der Erkennung eines Indikators für einen möglichen wartungsbedürftigen
Zustand oder ein mögliches
wartungsbedürftiges
Ereignis, wie. z.B. eine Fehlfunktion, einen Ausfall oder einen
unregelmäßigen Betrieb, automatisch
erzeugt werden. In ähnlicher
Weise kann eine Anbieterwartungsanforderung 34 automatisch
oder manuell erzeugt werden. Eine Anbieterwartungsanforderung 34 kann
z.B. beim Erkennen eines neuen oder zuvor unbekannten Zustandes oder
möglichen
Problems in den gewarteten Systemen oder durch Außendienstingenieure,
Wartungsingenieure usw. erzeugt werden. Wenn der Anbieter in der
Lage ist, auf Informationen zuzugreifen oder mit Informationen beliefert
zu werden, die sich auf den Zustand oder die Performance des Systems
beziehen, kann sich die Anbieterwartungsanforderung 34 darüber hinaus
darauf stützen,
dass der Anbieter einen Indikator für ein wartungsbedürftiges
Ereignis oder einen wartungsbedürftigen
Zustand erkennt.
-
In
Abhängigkeit
von solchen Wartungsanforderungen und von Informationen in der ISKB
wird das Wartungsreaktionssystem 30 typischerweise auf Analyseroutinen
zugreifen, wie sie mit dem Bezugszeichen 36 bezeichnet
sind. Diese Analyseroutinen ermöglichen
es, dass die Wartungsanforderung und beliebige begleitende Daten,
wie z.B. eine Systemmomentaufnahme, wie sie unten beschreiben ist, verarbeitet,
strukturiert und analysiert werden usw.. Die Analyseroutinen ermöglichen
es auch, dass die Wartungsanforderung und beliebige begleitende
Daten mit den Informationen in der ISKB verglichen werden, um mögliche Reaktionen
auf die Wartungsanforderung und eine Priorisierung für die Reaktionen
festzulegen. Es kann angenommen werden, dass die unten beschriebenen
Priorisierungsverfahren durch solche Analyseroutinen auszuführen sind.
In Abhängigkeit
von den Anforderungen, den ISKB-Daten und den Analyseroutinen werden
danach von dem Wartungsreaktionssystem eine oder mehrere Wartungsempfehlungen
abgegeben, wie sie durch das Bezugszeichen 38 bezeichnet
sind. Diese können
die Form von Mitteilungen, Listen und detaillierten Informationen,
die an einer Wartungsworkstation angezeigt werden, bei dem Wartungsanbieter
erzeugten Berichten, an die gewarteten Systeme gesendeten Mitteilungen
usw. annehmen. Solche Wartungsempfehlungen können auch Zeitpläne und das
Verschicken bzw. Entsenden von Teilen, Technikern, Außendienstingenieuren,
das Bestellen von Teilen, den Versand von Teilen oder eine beliebige
aus einer Vielzahl von konventionellen Wartungsreaktionen enthalten.
Wo es angebracht ist, können
die Wartungsempfehlungen auch eine tatsächliche Wartung enthalten, die
bei dem gewarteten Systemen oder von diesen entfernt durchgeführt wird,
wie z.B. durch Versenden eines Servicepakets oder von Software an
das gewartete System. Solche Pakete können z.B. verwendet werden,
um die Software, Firmware oder sogar Hardware, die auf dem Wartungssystem
installiert und betreibbar ist, zu neu zu konfigurieren, zurückzusetzen
oder in anderer Weise zu beeinflussen.
-
Nach
der Empfehlung werden typischerweise einige Arten von Wartungsmaßnahmen
durchgeführt,
wie es in 1 mit dem Bezugszeichen 116 bezeichnet
und unten beschrieben ist. In Abhängigkeit von der durchgeführten Wartungsmaßnahme können die
Wartung und die Empfehlung in einer geeigneten Weise ausgewertet
werden, wie z.B. durch Messen der Auswirkung (in Abhängigkeit
von der Natur des Systems, dem Zustand und der Art der vorgenommenen
Wartungsmaßnahme),
wie es mit dem Bezugszeichen 124 bezeichnet und ebenfalls
unten beschrieben ist. Es sollte erkannt werden, dass bestimmte
der in 1 zusammengefassten Funktionen zu einer Aktualisierung
oder einer anderen Korrektur oder Ergänzung der ISKB führen können, wie es
durch die zu der ISKB zurück
weisenden Pfeile in 1 eingezeichnet ist. Diese Aktualisierungsfunktion
bewirkt eine kontinuierliche Verstärkung, Korrektur und Verbesserung
der in der ISKB enthaltenen Wartungsinformationen.
-
2 stellt
ein beispielhaftes Verfahren zur Erzeugung der ISKB dar. Die beispielhafte
Logik, die allgemein mit dem Bezugszeichen 40 bezeichnet
ist, wird in eine Folge von Schritten zum Empfangen und Verarbeiten
der oben beschriebenen Datentypen unterteilt. Wie mit Blick auf 1 angemerkt
wird sich das ISKB-Erzeugungssystem typischerweise auf Systemdaten,
Problemlösungsdaten,
Instandhaltungsdaten und Indikatordaten stützen. Wie in 2 gezeigt
können
die Indikatordaten und die Lösungsdaten
in verschiedene spezielle Typen von Informationen weiter unterteilt
werden, die von bekannten Datenbanken, durch Experteneingabe, durch
Analyse von Instandhaltungsaufzeichnungen usw. erfasst werden können. Konkreter
können
direkte Indikatordaten 42 zusätzlich zu indirekten Indikatordaten 44 bereitgestellt
werden, wie es in 2 gezeigt ist. Direkte Indikatordaten
können
z.B. solche Informationen wie Spannungen, Ströme, eine Aktivierung von Indikatorlicht
oder -alarm usw. enthalten, die für mögli che wartungsbedürftige Zustände, Ausfälle, Fehlfunktionen
oder entstehende Zustände,
die eine Wartung erfordern können,
direkt kennzeichnend sind. Die indirekten Indikatordaten 44 können Parameterinformationen
enthalten, die nicht direkt mit einem speziellen Fehlertyp korreliert
sind, sondern aus denen typischerweise in Kombination mit anderen
Informationen Hinweise auf unregelmäßige Zustände und ihre Orte und Ursachen
abgeleitet werden können. Wie
von Fachleuten erkannt wird, können
in Abhängigkeit
von der Natur und dem Betrieb der gewarteten Systeme viele verschieden
Arten von Indikatoren bestimmt werden. Allgemein ermöglichen
die Indikatoren eine Erkennung und Lokalisierung der Ursachen von
wartungsbedürftigen
Zuständen
und Ereignissen, wobei eine übermäßige Redundanz
vermieden wird, die die Ressourcen des Wartungsreaktionssystems
unnötig
belasten könnte.
-
Zusätzlich zu
den Indikatordaten kann auf Daten 46 wahrscheinlicher Ursachen
zugegriffen werden, wo sie verfügbar
sind. Solche Daten 46 wahrscheinlicher Ursachen können in
praktischen Anwendungen inhärent
mit den direkten Indikatordaten und den indirekten Indikatordaten
verknüpft
sein, wobei sie in Kombination mit solchen Daten einen Hinweis auf
eine potentielle Fehlfunktion sowohl in der Software als auch in
der Hardware liefern. Wo es angebracht ist, können die Daten wahrscheinlicher Ursachen
im Hinblick auf den Ort und die Grundursache einer Fehlfunktion
ziemlich spezifisch sein, oder sie können auf ein bestimmtes Programm,
eine Routine innerhalb eines Programms, eine am Einsatzort austauschbare
Einheit, eine Komponente usw. beschränkt sein. Wie von Fachleuten
erkannt wird, kann der Grad der Lokalisierung der endgültigen Grundursache
der Fehlfunktion weitere und zusätzliche
Indikatoren erfordern. Die wirtschaftliche Wartung der Systeme kann
den für
die Wartung gewünschten Grad
der Lokalisierung der Grundursache mit sich bringen. Das bedeutet,
dass eine praktische Wartungsempfehlung z.B. den Austausch verschiedener Komponenten
als eine am Einsatzort austauschbare Einheit oder ein erneutes Laden
oder erneutes Konfigurieren eines Softwareblocks enthalten kann, selbst
wenn die endgültige
Grundursache theoretisch durch mehr Investitionen in Sensoren sowie
Datensammlung und -analyse bestimmt werden könnte.
-
Reaktionsempfehlungsdaten 48 werden ebenfalls
berücksichtigt,
wo sie verfügbar
sind. In einer typischen ISKB werden z.B. bekannte Probleme und „Fixes" zum Bestücken der
ISKB verfügbar
sein, und weitere Empfehlungen können
mit der Zeit verfügbar
werden. Diese können
mit speziellen direkten oder indirekten Indikatoren und, wo es möglich ist, mit
möglichen
Grundursachen einer Fehlfunktion verknüpft werden.
-
Wie
oben erörtert
kann man sich für
die Verarbeitung der Daten, auf die zugegriffen wird, auf verschiedene
Analyseroutinen stützen,
die unter dem Bezugszeichen 50 zusammengefasst sind. Die
Analyseroutinen können
die in 2 zusammengefasste Verarbeitung sowie weitere
Verarbeitung zulassen, wo es angebracht ist.
-
Wie
in 2 zusammengefasst beginnt die Verarbeitung mit
einer Analyse der Daten, auf die zugegriffen wird, wie es mit dem
Bezugszeichen 52 bezeichnet ist. Eine solche Analyse wird
typischerweise eine Erkennung von Zuordnungen zwischen den Daten,
auf die zugegriffen wird, und einzelnen Systemen oder Systemtypen
enthalten. In den meisten komplexen Systemen können zahlreiche verschiedene
Parameter überwacht
werden, und ihre Werte oder Bereiche können gespeichert werden. Die
Analyse kann auch eine Bestimmung der Relevanz der Daten, auf die
zugegriffen wird oder die verfügbar sind,
enthalten, um festzustellen, welche von zahlreichen verschiedenen überwachten
Parameterwerten und -bereichen, die verfügbar sind, als Indikatoren
für eine
mögliche
Fehlfunktion von besonderem Interesse sind und welche weniger relevant
sein können
und nicht aufbewahrt werden, um sich einer Serviceanforderung zuzuwenden.
Wo es erwünscht
ist, können die
Daten, auf die zugegriffen wird, strukturiert werden, um einen späteren Zugriff
auf sie, einen Vergleich und eine Zuordnung zu anderen in der ISKB gespeicherten
Daten zu erleichtern, wie es in dem Schritt 54 bezeichnet
ist. In dem Schritt 56 werden die Daten z.B. aufgezeichnet
und klassifiziert, um die Daten verschiedenen einzelnen Systemen
und Systemtypen, einzelnen Indikatoren, Gruppen von Indikatoren,
möglichen
Grundursachen und Problemen und Reaktionen und Wartungsempfehlungen
zuzuordnen. In ähnlicher
Weise werden Korrelationen zwischen den Indikatoren, Ursachen und
Empfehlungen hergestellt, wie es in dem Schritt 58 bezeichnet ist.
Diese Korrelationen werden typischerweise durch eine relationale
Datenbank hergestellt, wobei eine Datenstruktur erstellt wird, die
die ISKB bilden wird.
-
Wie
es in dem Schritt 60 in 2 bezeichnet und
unten genauer erörtert
ist, können
die Reaktionen und Empfehlungen nach Vorrangigkeit geordnet und
die Priorisierungen als Priorisierungswerte in der ISKB gespeichert
werden. Eine solche Priorisierung kann auf die Schwere der Grundursachen
einer Fehlfunktion, die endgültigen
Kosten der Fehlfunktion oder der Reparatur, die aus der Fehlfunktion
folgende Ausfallzeit usw. gestützt
sein. Wo mehrere mögliche Grundursachen
und Empfehlungen vorliegen, werden solche Priorisierungswerte daher
unter den Empfehlungen eine Hierarchie aufstellen, nach der die
Systeme automatisch oder mit dem Eingriff durch Bedienungspersonal
in einer bestimmten Reihenfolge in Abhängigkeit von der Priorisierung
handeln würden.
-
Wie
in Schritt 62 in 2 bezeichnet
ist allgemein ein Überprüfungsverfahren
angebracht, um zu überprüfen, dass
die Indikatoren, die Hinweise auf Grundursachen und die Empfehlungen
für die
Wartungssysteme korrekt sind. Das Überprüfungsverfahren kann z.B. durch
Systemexperten durchgeführt werden.
Die Überprüfung kann
auch eine Überprüfung der
Priorisierung der Wartungsreaktionen und -empfehlungen enthalten.
Wie durch den von dem Block 62 in 2 wegweisenden
Pfeil bezeichnet, kann diese Überprüfung zu Änderungen
in irgendeinem der vorangegangenen Schritten führen, die zum Erzeugen der
ISKB verwendet werden. Solche Änderungen
können
z.B. ein Hinzufügen
oder Entfernen von Parameterindikatoren, ein Hinzufügen, Entfernen
oder Ändern
von Empfehlungen und Reaktionen und Änderungen der Priorisierungswerte
enthalten. In dem Schritt 64 wird die ISKB endgültig gespeichert,
um sie zu benutzen, um sich den Belangen der Wartung zuzuwenden.
-
3 stellt eine beispielhafte Logik zum
Verarbeiten einer Wartungsanforderung gemäß Aspekten der vorliegenden
Vorgehensweise dar. Die Verarbeitungslogik, die allgemein mit dem
Bezugszeichen 66 bezeichnet ist, beginnt mit dem Empfangen
der Wartungsanforderung in dem Schritt 68. Die Wartungsanforderung
wird typischerweise in elektronischer Form gesendet, wie z.B. über eine
elektronische Mitteilung oder dergleichen. Die Wartungsanforderung
kann Informationen, wie z.B. die Systembezeichnung und relevante
Informationen zudem Problem enthalten, das in dem System aufgetreten
sein kann. Darüber
hinaus kann die Wartungsanforderung in einer gegenwärtig in
Betracht gezogenen Ausführungsform
eine Anzahl von zusätzlichen
Komponenten und unterstützenden
Informationen enthalten, wie z.B. einen Namen oder eine Bezeichnung
der Anforderung, die Herkunft der Anforderung, eine Bezeichnung
der Häufigkeit
der Anforderung (z.B. die Anzahl der Male, in denen eine ähnliche
Anforderung gestellt worden ist), eine Kundenidentifizierung, eine Benutzeridentifizierung,
einem Kontakt zu einem Außendiensttechniker
usw. enthalten. Zusätzlich
zu diesen Grundinformationen kann die Anforderung tatsächliche
Protokolldaten und Karteidaten enthalten, die beim Erkennen des
wartungsbedürftigen
Zustands oder Ereignisses und der Grundursache für die Fehlfunktion und beim
Empfehlen einer Wartungsreaktion helfen können. Solche Informationen können z.B.
Protokolldateien, Bilddateien, Audiodateien, Videodateien, Textdateien
und Dateien, die in anderer Weise überwachte Parameter bezeichnen, die
als Indikatoren dienen könnten,
die nützlich
sind, um sich der Wartungsanforderung zuzuwenden, enthalten.
-
Gemäß bestimmten
Aspekten der vorliegenden Vorgehensweise kann die Wartungsanforderung auch
Konfigurationsdaten enthalten. In einer gegenwärtig in Betracht gezogenen
Ausführungsform
können
solche Daten die betroffenen Geräte
und jeden verfügbaren
Wartungsverlauf des Systems oder der einzelnen betroffenen Geräte bezeichnen.
Die Konfigurationsdaten können
Softwarekonfigurationsdaten sowie Hardwarekonfigurationsdaten enthalten.
Die Hardwarekonfigurationsdaten sind insbesondere beim Erkennen
der Grundursachen von Problemen und beim Ausschließen von
Grundursachen nützlich, wo
Hardware oder Komponenten nicht installiert oder nicht aktiviert
sind. Die Hardware- und Softwarekonfigurationsinformationen können wie
unten beschrieben in einer „Momentaufnahme" erfasst und auf
dem System oder entfernt von dem System in einer Protokolldatei
gespeichert werden. Eine Einbeziehung dieser Informationen und einer
Wartungsanforderung erleichtert das Festlegen einer geeigneten Reaktion auf
die Wartungsanforderung sowie die Priorisierung von Reaktionen weiter,
wo mehrere Reaktionen möglich
sind. Wie oben angemerkt können
die Informationen auch dazu dienen, bei einem Wartungsdienstanbieter
Prioritäten
zwischen Wartungsmaßnahmen
festzulegen, die für
verschiedene Systeme zu erbringen sind.
-
Das
Verfahren aus 3 schreitet mit einer Analyse
der Wartungsanforderung fort, wie es mit dem Bezugszeichen 70 bezeichnet
ist. Eine solche Analyse wird ein Parsing oder ein Strukturieren
der Informationen der Wartungsanforderung enthalten. In dem Schritt 72 kann
die Wartungsanforderung nach Vorrangigkeit eingeordnet werden. Wie
unten genauer erörtert
kann eine solche Priorisierung auf einen in der ISKB gespeicherten
Priorisierungswert oder auf andere als in der ISKB berücksichtigte
Faktoren, einschließlich
vom Wartungsvertrag abhängiger
und weiterer Faktoren gestützt
sein.
-
In
dem Schritt 74 werden eine oder mehrere Wartungsreaktionen
empfohlen. Mehrere verschiedene Typen von Wartungsreaktionen werden
gegenwärtig
in Betracht gezogen. Diese können
allgemein gruppiert werden, wie es mit dem Bezugszeichen 116 bezeichnet
ist. Die Wartungsreaktionen können
z.B. einen einfachen Bericht über
den Vorfall an das Systempersonal sowie an Wartungsdienstanbieter,
Außendienstingenieure
usw. enthalten, wie es mit dem Bezugzeichen 76 bezeichnet
ist. Insbesondere bei bestimmten Systemen, die zum automatischen
Erzeugen einer Wartungsanforderung in der Lage sind, könnte sich
der Systemaufseher, das Management, der Eigentümer oder eine andere verantwortliche Person
nicht einmal des Vorfalls oder des Wartungsbedarfs bewusst sein.
Der in dem Schritt 76 erzeugte Bericht liefert solche Informationen.
Außerdem
kann der Bericht nützliche
Informationen zum Entsenden von Außendienstingenieuren, zum Benachrichtigen der
Techniker vom Auftreten der Wartungsanforderung usw. liefern.
-
Weiterhin
könnte
eine Reaktion ein Anfordern von zusätzlichen Daten enthalten, wie
es mit dem Bezugszeichen 78 bezeichnet ist. Solche zusätzlichen
Daten können
sich aus dem Wartungsreaktionssystem ergeben, das erkennt, dass
unzureichende Daten verfügbar
oder übermittelt
worden sind, um eine ausreichende Empfehlung abzugeben oder zwischen
möglichen
Grundursachen oder Empfehlungen zu unterscheiden. Solche zusätzlichen
Daten können
automatisch oder durch einen Bedienereingriff oder durch einen Wartungstechniker
oder andres Wartungspersonal angefordert werden.
-
Schließlich können spezielle
Handlungen vorgenommen werden, wie es mit dem Bezugszeichen 80 bezeichnet
ist. Diese können
das relativ konventionelle Entsenden eines Wartungstechnikers, aber
auch hoch automatisierte Reaktionen enthalten. Bestimme Einstellungen
an dem gewarteten System können
z.B. über
Fernverbindungen und -links automatisch geändert werden, wo es angebracht
ist, wie z.B. durch die Übertragung
eines Servicepakets an das System. In ähnlicher Weise können Konfigurationsdaten
zum Neukonfigurieren oder Zurücksetzen (z.B.
Neukalibrieren) bestimmter Komponenten an das System gesendet werden.
Geeignete Reaktionen können
auch das Aufgeben einer Bestellung von bestimmten Teilen oder Komponenten oder
sogar das Versenden bestimmter Teile oder Komponenten für einen
möglichen
Austausch in dem System enthalten.
-
Gestützt auf
irgendwelche derartigen Wartungsreaktionen kann die ISKB zur Verbesserung
aktualisiert werden, wie es mit dem Bezugszeichen 128 bezeichnet
und unten genauer erläutert
ist.
-
Die
Wartungsanforderungen, Empfehlungen und Wartungshandlungen können gemäß Aspekten der
vorliegenden Vorgehensweise nach Vorrangigkeit geordnet werden,
einschließlich
durch das Speichern spezifischer Priorisierungswerte für Grundursachen,
Indikatoren, vorgeschlagene Reaktionen und dergleichen. In einer
gegenwärtig
in Betracht gezogenen Ausführungsform
werden diese Priorisierungswerte erzeugt, wenn die ISKB erstellt
wird. Als Teil der Analyseroutinen, die durch das ISKB-Erzeugungssystem
implementiert werden, kann eine Priorisierungsmaschine 82 aufgerufen
werden, wie sie in 4 dargestellt ist. Die Priorisierungsmaschine 82 kann
im Wesentlichen aus Software bestehen, die durch den Computer oder
die Computer, die die ISKB bilden, auf der Grundlage einer Priorisierungslogik implementiert
wird. Eine solche Logik wird typischerweise in Abhängigkeit
von der Natur des Systems, der Funktion des Systems usw. variieren.
Die Priorisierungslogik kann an den Systemtyp angepasst und für diesen
Systemtyp speziell ausgelegt sein. Die Konstrukteure einer bestimmten
ISKB werden typischerweise die Logik festlegen, und ihre Kodierung wird
als im Bereich kompetenter fachkundiger Programmierer liegend angesehen
und erfordert kein übermäßiges Experimentieren.
-
Die
Priorisierungsmaschine und -logik können auf eine beliebige Reihe
von Faktoren zugreifen, um die Rangordnung zwischen den Indikatoren, Grundursachen
und möglichen
Reaktionen auf Wartungsanforderungen zu erstellen. In der in 4 dargestellten
Ausführungsform
werden bestimmte dieser Faktoren als anforderungsunabhängig angesehen,
wie es mit dem Bezugszeichen 84 bezeichnet ist, während andere
als anforderungsabhängig
angesehen werden, wie es mit dem Bezugszeichen 86 bezeichnet
ist. Anforderungsunabhängige
Faktoren können
solche Faktoren wie z.B. eine Wahrscheinlichkeit für einen
Fehler oder eine Ausfallzeit, ein mit dem möglichen Fehler verbundenes
Risiko (z.B. in Begriffen der Ausfallzeit, des Risikos für Maschinen und
Umwelt etc.), die mögliche
Schwere des Problems oder Fehlers, mit dem Problem, Fehler oder der
Ausfallzeit zusammenhängende
Kosten und beliebige weitere Faktoren enthalten. Diese Faktoren sind
als anforderungsunabhängige
Faktoren gruppiert, weil sie sich nicht notwendigerweise auf die
Anforderung selbst beziehen, sondern mehr von dem System und Konsequenzen
abhängig
sind, die vom Auftreten des wartungsbedürftigen Ereignisses in dem
System ausgehen. Anforderungsabhängige Faktoren
könnten
solche Faktoren, wie etwa den die Anforderung stellenden Kunden,
die Häufigkeit,
mit der die Anforderung oder ähnliche
Anforderungen gestellt worden sind, die Ausfallzeit, die der Kunde erfährt oder
erfahren könnte,
die Wartezeit beim Reagieren auf die Wartungsanforderung, die der
Kunde erfahren hat oder erfahren könnte, und die betroffenen Geräte oder
weitere Faktoren enthalten. Solche Faktoren beziehen sich mehr auf
die Anforderung selbst oder die Quelle oder Natur der Anforderung. Gestützt auf
solche Faktoren kann den verschiedenen bekannten Indikatoren, Grundursachen
und Reaktionen ein Priorisierungswert zugewiesen werden.
-
5 zeigt
in etwas genaueren Details eine beispielhafte Logik, um empfangene
Wartungsanforderungen nach Vorrangigkeit zu ordnen. Die Logik, die
allgemein mit dem Bezugszeichen 88 bezeichnet ist, beginnt
mit der Anforderung selbst 32, 34 und der ISKB 28,
auf die von einer Schnittstelle 90 zugegriffen wird. Wie
oben angegeben wird die Schnittstelle typischerweise dazu ausgerüstet sein,
Anforderungen automatisch zu empfangen, wie z.B. durch eine elektronische Übertragung,
sowie entweder lokal oder über
eine Fernverbindung auf die ISKB zuzugreifen. Die Anforderung und
die Informationen von der ISKB können
strukturiert werden, wie es in dem Schritt 92 bezeichnet
ist. Wie oben angegeben wird die ISKB typischerweise vorstrukturiert
sein, um eine Bezugnahme auf die Daten zu erleichtern, die sie enthält. Darüber hinaus
kann die Anforderung auch strukturiert sein, aber sie kann unstrukturierte
oder teilweise strukturierte Daten enthalten, die in dem Schritt 92 strukturiert
werden, um eine Auswertung der Wartungsanforderung und ihren Vergleich
mit Informationen in der ISKB zu ermöglichen.
-
In
dem Schritt 94 werden die Details der Wartungsanforderung
extrahiert. Diese Details können alle
oben beschriebenen Inhalte enthalten, die in der Wartungsanforderung
enthalten sein können,
einschließlich
der Systembezeichnung, der Bezeichnung des wartungsbedürftigen
Ereignisses oder Zustands, Ortsinformationen, Informationen zur
Wartungsgeschichte, Protokolldateien, Hardwarekonfigurationen, usw..
In dem Schritt 95 werden diese Informationen in der ISKB
aufgezeichnet. Diese Aufzeichnung kann einen einfachen Vergleich
einzelner Felder oder Datenstrukturen mit sich bringen oder eine
detailliertere Logik enthalten. Diese Logik kann z.B. auf ein Auswerten
spezieller Indikatoren und ein Korrelieren solcher Indikatoren mit
potentiellen Grundursachen und Wartungsempfehlungen gestützt sein.
In dem Schritt 98 kann das System auswerten, ob in der
Wartungsanforderung ausreichende Informationen empfangen worden
sind. Wenn unzureichende Informationen empfangen worden sind, können weitere
Informationen angefordert werden, wie es in dem Schritt 100 bezeichnet
ist. Solche zusätzlichen
Informationen können
z.B. die oben beschriebenen Hardwarekonfigurationsinformationen, Fehlerdateien,
Protokolldateien oder beliebige Parameterdaten enthalten, die als
ein Indikator für
die Natur des wartungsbedürftigen
Zustands oder Ereignisses und eine mögliche Grundursache und empfohlene
Lösung
dienen können.
-
Wo
mehr als eine mögliche
Reaktion verfügbar
ist, kann dies in dem Schritt 102 bewertet werden. Wenn
nicht mehr als eine Reaktion verfügbar ist, kann die Verfahrensablauf
fortschreiten, und die einzige verfügbare Empfehlung kann wie unten
erörtert abgegeben
werden. Wo mehr als eine Reaktion verfügbar ist, können diese jedoch in dem Schritt 104 in Einklang
gebracht werden. Das In-Einklang-Bringen der verfügbaren Reaktionen
kann eine Entfernung bestimmter Reaktionen, eine Einbeziehung bestimmter
Reaktionen usw. enthalten. Ein solches In-Einklang-Bringen kann
gestützt
auf Regeln, die in der ISKB enthalten sind oder durch das Wartungsreaktionssystem
implementiert werden, automatisch durchgeführt werden. Ein solches In-Einklang-Bringen
kann auch in Abhängigkeit
von einer Eingabe von Wartungstechnikern, Experten und dergleichen durchgeführt werden.
-
In
einem Schritt 106 kann eine Rangordnung zwischen oder unter
möglichen
Reaktionen erstellt werden. Wie oben angege ben kann diese Rangordnung
zwischen möglichen
Reaktionen auf einen einzigen wartungsbedürftigen Zustand oder möglichen wartungsbedürftigen
Zuständen
innerhalb eines einzelnen Systems bestehen, oder sie kann zwischen Systemen
vorliegen. Das bedeutet, dass dort, wo ein Wartungsdienstanbieter
die Wartung einer Anzahl von verschiedenen Systemen oder Kunden
anbietet, bestimmte wartungsbedürftige
Zustände
eine höhere Präzedenz gegenüber anderen
annehmen können, so
dass es die Rangordnung zwischen und unter der Wartungsanforderung
und den möglichen
Reaktionen erfordern kann, dass man sich bestimmten Anforderungen
auf der Grundlage einer höheren
Dringlichkeit zuwendet. Die in dem Schritt 106 festgelegte Rangordnung
kann daher auf der Grundlage der Priorisierungswerte, die in der
ISKB gespeichert sind oder während
der Verarbeitung abgeleitet werden, relativ objektiv festgelegt
werden. In dem Schritt 108 können diese Rangordnungen angepasst
werden. Anpassungen der Rangordnungen können manuell oder gestützt auf
automatisierte Regeln vorgenommen werden. Die Rangordnungen können z.B.
in Abhängigkeit
von einer Kundenbezeichnung, einer Systembezeichnung oder breiter
in Abhängigkeit
von Serviceverträgen
angepasst werden. Wo z.B. mehrere Stufen von Wartungsverträgen angeboten
werden, kann der Wartungsdienstanbieter bestimmten Typen von erstklassigen
Wartungsverträgen
eine höhere Priorität garantieren,
während
anderen Wartungsverträgen
eine normale Stufe in der Rangordnung zugewiesen wird. Für den Anpassungsvorgang
kann Zugriff auf solche Informationen genommen werden, wie es in
dem Schritt 100 in 5 bezeichnet
ist.
-
Gestützt auf
die Priorisierung oder, wenn eine einzige Empfehlung abzugeben ist,
werden die Empfehlungen ausgegeben, wie es in dem Schritt 112 bezeichnet
ist. Wie oben angegeben können
die Empfehlungen eine beliebige Reihe von möglichen Reaktionen auf eine
Wartungsanforderung enthalten. Allgemein wird das System oder der
Systemeigentümer
jedoch benachrichtigt, wie es in dem Schritt 114 bezeichnet
ist. Diese Benachrichtigung kann auch and den Wartungsdienstanbieter,
verantwortliches Personal bei einem Kunden und bei dem Wartungsdienstanbieter,
Außendienstingenieure
und -techniker usw, ergehen. Schließlich wird in dem Schritt 116 eine
Art von Wartungsaktivität
allgemein in Ordnung sein. Wie ebenfalls oben angegeben kann diese
Wartung eine tatsächliche
Inspektion am Einsatzort oder einen Kontakt mit dem System oder
ein automatisiertes „Fix" enthalten, um sich
dem nicht wartungsfähigen
Zustand zuzuwenden. Weitere Reaktionen und Wartungsmaßnahmen
könnten
jedem konventionellen Typ von Reaktion folgen, einschließlich regelmäßigen oder
speziell geplanten Wartungsmaßnahmen usw..
Auch die Benachrichtigung 114 kann strukturiert sein, wie
es in dem Block 92 neben dem Block 114 in 5 bezeichnet
ist, um eine Aktualisierung und eine Verbesserung der Daten in der
ISKB zu erleichtern.
-
6 stellt
eine beispielhafte Logik zum Aktualisieren der ISKB in Abhängigkeit
von der tatsächlichen
Wartung und tatsächlichen
Rückmeldungen dar.
Die Logik aus 6 kann mit der Feststellung beginnen,
ob in der ISKB ein korrelierbares, wartungsbedürftiges Ereignis oder ein korrelierbarer wartungsbedürftiger
Zustand vorhanden ist, wie es mit dem Bezugszeichen 118 bezeichnet
ist. Wie oben angegeben kann die ISKB auf vorhandene Informationen
und vorhandenes Wissen des gewarteten Systems gestützt sein.
Es ist jedoch möglich
und sogar wahrscheinlich, dass neue wartungsbedürftige Zustände erkannt werden und Indikatoren
und die Reaktionen vorgeschlagen und vorgenommen werden, um sich
Wartungsanforderungen auf der Grundlage neu erkannter Zustände zuzuwenden.
Wenn der Zustand oder das Ereignis nicht in der ISKB enthalten ist,
kann diesen ein Rang zugewiesen werden, wo die ISKB Priorisierungswerte
enthält,
und die Informationen können
der ISKB hinzugefügte
werden, um sich zukünftigen
Anforderungen ähnlicher
Art zuzuwenden, wie es durch das Bezugszeichen 120 bezeichnet
ist. Wo solche Daten eine Strukturierung erfordern, um ihre Einbeziehung
in die ISKB zu erleichtern, wird dies wie zuvor in dem Schritt 92 gefolgt
von einer Aktualisierung der ISKB in dem Schritt 128 durchgeführt.
-
Wo
der Zustand oder das Ereingis bereits in der ISKB enthalten ist,
kann der Wartungsanforderung oder der Reaktion ein Rang zugewiesen
werden, und die Rangordnung kann wie oben beschrieben und in den
Schritten 106 und 108 in 6 bezeichnet
angepasst werden. Wie ebenfalls oben angegeben kann die Wartung
in Abhängigkeit
von diesen Empfehlungenen letztendlich vorgenommen werden, wie es
in dem Schritt 116 in 6 bezeichnet
ist.
-
In
Abhängigkeit
von dieser vorgenommenen Wartungsmaßnahme kann eine Rückmeldung
erhalten werden, wie es in dem Schritt 122 bezeichnet ist, wie
z.B. von dem System selbst, einem Kunden oder von verantwortlicher
Seite oder von dem Außendienstingenieur
oder -techniker. Um den maximalen Nutzen zu erbringen, wird die
Rückmeldung
ausgewertet, um festzustellen, ob das Ergebnis der Wartungsmaßnahme so
war, wie es auf der Grundlage der Informationen in der ISKB erwartet
worden wäre, wie
es in dem Schritt 124 bezeichnet ist. Wenn die Rückmeldung
positiv ist (d.h. die Wartungsmaßnahme hatte das erwartete
Ergebnis), kann in der ISKB ein derartiger Vermerk gemacht werden,
wie es mit dem Bezugszeichen 126 bezeichnet ist. Eine solche positive
Rückmeldung
kann dazu dienen, die Informationen in der ISKB zu untermauern und
sogar den Priorisierungswert für
solche Reaktionen erhöhen. Wenn
das erwartete Ergebnis nicht erhalten worden ist, kann die ISKB
andererseits aktualisiert werden, wie es in dem Schritt 128 bezeichnet
ist. Eine solche Aktualisierung kann umgekehrt zu einer Verringerung eines
Priorisierungswertes für
die Empfehlung führen,
die tatsächlich
in die Praxis umgesetzt worden ist. Allgemein kann in dem Schritt 130 eine
Art von Notiz oder Flag erzeugt bzw. gesetzt werden, die bzw. das
dem Manager der ISKB anzeigt, dass das Update vorgenommen worden
ist oder vorgenommen werden sollte.
-
Ein
besonders nützlicher
Aspekt der vorliegenden Vorgehensweise beinhaltet die Erzeugung einer
Systemmomentaufnahme. Wie oben angegeben kann die Systemmomentaufnahme
eine Reihe von Informationen enthalten, die sich auf den Zustand
des gewarteten Systems zu dem Zeitpunkt des Auftretens eines wartungsbedürftigen
Ereignisses oder Zustands beziehen. Wenn der Indikator oder die Indikatoren
für das
wartungsbedürftige
Ereingis oder den wartungsbedürftigen
Zustand erkannt werden, kann die Systemmomentaufnahme erzeugt werden. Wie
in 7 dargestellt kann die Systemmomentaufnahme, die
allgemein mit dem Bezugszeichen 132 bezeichnet ist, eine
Reihe von Informationen und Daten enthalten, die dann in dem System
vorliegen sind. Am nützlichsten
wird die Systemmomentaufnahme gleichzeitig mit oder sehr kurz nach
der Erkennung des Indikators für
den wartungsbedürftigen
Zustand oder das wartungsbedürftige
Ereignis erzeugt.
-
Es
sollte bemerkt werden, dass die Momentaufnahme Daten enthalten kann,
die vor der Erkennung des Indikators, zum tatsächlichen Zeitpunkt derselben
oder nach derselben tatsächlich
gesammelt worden sind. Allgemein wird die Momentaufnahme jedoch
Daten enthalten, die zu einem Zeitpunkt oder in einer Zeitspanne
oder einem Zeitfenster gesammelt werden, die in Abhängigkeit
von dem Zeitpunkt der Erkennung des Indikators festgelegt werden.
Wo der Indikator einen früheren
Zeitpunkt des Auftretens oder des Beginns eines Zustandes andeutet,
kann die Momentaufnahme z.B. Daten enthalten, die der Systemkonfiguration
zu dem früheren
Zeitpunkt entsprechen. Wo eine Entwicklung oder ein Verlauf des
Zustands von Interesse ist, können
frühere
und spätere
Daten gesammelt werden. Es sollte auch erkannt werden, dass die
Erfassung der Momentaufnahme und der Zeitabschnitt der gesammelten
Daten von anderen Parametern als der Zeit abhängen können, wie z.B. von Zählwerten
von Benutzungen, Zyklen usw.. Für
die vorliegenden Zwecke sollten diese ebenfalls als auf den „Zeitpunkt" der Erkennung des
Indikators oder des Auftretens des Indikators gestützt angesehen
werden.
-
Die
Systemmomentaufnahme kann z.B. die Bedingungen des Auftretens oder
der Erkennung des Indikators, bestimmte Gerätedaten, beliebige Protokolldaten
und Fehlerdaten, Ortsdaten und Kundendaten enthalten, wie es jeweils
durch die Bezugszeichen 134, 136, 140 und 141 bezeichnet
ist. Die Zeitdaten werden typischerweise einen Hinweis auf das Datum,
die Stunde und Minute oder sogar die Sekunden enthalten, zu denen
der Indikator erkannt worden ist. Die Gerätedaten 136 können Softwarekonfigurationsinformationen,
historische Parameter, Bilder und andere Dateien, die in dem System
vorhanden sind, sowie eine Reihe von Parametern und ihre Werte,
die dann in dem System vorhanden sind, enthalten.
-
In
dem vorliegenden Ausführungsbeispiel sind
Hardware- und Softwarekonfigurationsinformationen
von besonderem Interesse. Solche Hardwarekonfigurationsinformationen
können
z.B. Komponenten, die in dem System installiert sind und betrieben werden,
Peripheriegeräte,
die in dem System installiert sind und betrieben werden, Teile,
Einstellungen, Verbindungen, die zu dem Zeitpunkt des Auftretens bestehen,
usw. enthalten. Die Fehlerdaten und Protokollinformationen 138 können z.B.
Fehlernamen, Fehlerhäufigkeiten,
beobachtete Parameter außerhalb
der erwarteten Bereiche oder der Toleranzbereiche usw. enthalten.
Die Ortsinformationen 140 können Informationen, wie z.B.
das System, Teilsystem oder sogar eine Komponente oder eine vor
Ort austauschbare Einheit, von denen ein Indikator stammt, sowie
eine Bezeichnung des Systems, Systemorts, Kunden usw. enthalten.
Die Kundendaten 141 können
Informationen, wie z.B. solche Informationen wie die Kunden- und
Systemnummern oder -bezeichnungen, Informationen, die sich auf den
Kunden oder auf Zustände
des Verkaufs oder der Lieferung beziehen, usw. enthalten.
-
8 gibt
beispielhafte Schritte beim Erzeugen der Systemmomentaufnahme wieder.
Die Momentaufnahmenerzeugungslogik, die allgemein mit dem Bezugszeichen 142 bezeichnet
ist, kann mit der Erkennung eines Problems beginnen, wie es in dem Block 144 bezeichnet
ist. Tatsächlich
kann die Systemmomentaufnahme bei der Erkennung irgendeines interessierenden
Indikators, insbesondere derjenigen Indikatoren aufgenommen werden,
die zum Erkennen einer Grundursache eines Problems, Erkennen eines
möglichen
wartungsbedürftigen
Ereignisses oder Zustands oder Identifizieren möglicher Reaktionen auf das
Ereignis verwendet werden können. Darüber hinaus
kann die Momentaufnahme beim Erkennen irgendeines Indikators aufgenommen werden,
der dazu benutzt werden kann, dabei zu helfen, die wartungsbedürftigen
Ereignisse und Zustände oder
die Reaktionen auf diese nach Priorität zu ordnen. Wie mit dem Bezugszeichen 146 bezeichnet können derartige
Momentaufnahmen darüber
hinaus auf eine Anforderung, wie z.B. von einem Bediener aufgenommen
werden. Es sollte erkannt werden, dass der Bediener sich lokal bei
dem gewarteten System befinden kann oder von dem System entfernt sein
kann. Folglich kann die Systemmomentaufnahme auf einen manuellen
Eingriff hin eingeleitet werden, wie z.B. wenn ein unregelmäßiger Zustand
in einem System vermutet wird. Dies kann als Reaktion auf eine lokale
Anforderung oder auf eine Anforderung von einem entfernten Wartungsdienstanbieter oder
irgendeinem anderen Bediener erfolgen.
-
In
dem Schritt 148 wird die Systemmomentaufnahme aufgenommen.
Wie oben unter Bezug auf 7 angegeben wird die Systemmomentaufnahme durch
Zugreifen auf bestimmte Dateien und Daten aufgenommen, und die Momentaufnahme
wird in einer Protokolldatei gespeichert, wie es in dem Schritt 150 bezeichnet
ist. Die einzelnen in der Systemmomentaufnahme zu speichernden Elemente
können
in dem gewarteten System definiert und gespeichert werden. Wie von
Fachleuten erkannt wird, können solche
Informationen und Anweisungen zum Einleiten der Systemmomentaufnahme
in der ISKB definiert sein und auf das System herunter geladen werden,
um die für
die Erzeugung der Systemmomentaufnahme benötigten Anweisungen festzulegen.
Die Anweisungen können
auch einen bestimmten Arbeitsablauf enthalten, der an den erfassten
Daten oder Dateien durchzuführen
ist.
-
In
dem Schritt 152 in 8 kann eine
Fehlermeldung angezeigt werden, die darauf hinweist, dass der Indikator
für ein
potentiell wartungsbedürftiges Ereignis
oder einen potentiell wartungsbedürftigen Zustand erkannt worden
ist, wo es angebracht ist. Solche Anzeigen von Fehlermeldungen sind
insbesondere in Systemen wünschenswert,
in denen ein menschlicher Bediener bestimmte Arten von Handlungen
vornehmen kann. In dem medizinischen diagnostischen Zusammenhang
können
komplexe Systeme z.B. von klinischen Ärzte, Technikern, Radiologen und
anderen Fachleuten gesteuert werden. Die Anzeige der Fehlermeldung
in dem Schritt 152 informiert den Bediener, dass die Systemmomentaufnahme
aufgenommen worden ist und irgendeine Handlung erforderlich sein
kann, wie z.B. das Einleiten oder Übermitteln einer Wartungsanforderung.
-
In
dem Schritt 154 kann der Bediener aufgefordert werden,
die Momentaufnahme oder eine Wartungsanforderung oder beide an einen
Wartungsdienstanbieter zu senden, um sich dem potentiell wartungsbedürftigen
Zustand oder Ereignis zuzuwenden. In Abhängigkeit von einer Bedienerauswahl kann
danach ein Bericht gesendet werden, wie es mit dem Bezugszeichen 156 bezeichnet
ist. In einer vorliegenden Ausführungsform
wird die Systemmomentaufnahme in einer Protokolldatei 158 gespeichert, egal
ob der Bericht gesendet worden ist oder nicht. Weil bestimmte Ereignisse
kein unmittelbares Hindernis für
eine Fortsetzung des Betriebs oder sogar für einen normalen Betrieb des
Systems darzustellen brauchen, kann die automatische Speicherung
der Systemmomentaufnahme in einer Protokolldatei, wie sie in dem
Schritt 158 bezeichnet ist, eine spätere Auswertung des Gesundheitszustands
des Systems, Wartung des Systems usw. stark vereinfachen. Auf die
Dateien kann z.B. durch Wartungspersonal oder sogar von Ferne bei
Routine kontrollen oder bei einer Wartung des Systems zugegriffen
werden.
-
Während hierin
nur bestimmte Merkmale der Erfindung dargestellt und beschrieben
worden sind, werden Fachleuten zahlreiche Abwandlungen und Änderungen
einfallen. Es muss daher erkannt werden, dass es beabsichtigt ist,
dass die beigefügten Ansprüche alle
solche Abwandlungen und Änderungen
umfassen, die unter den wahren Geist der Erfindung fallen.
-
Zusammenfassung
-
Es
wird eine Technik zum Erkennen von wartungsbedürftigen Zuständen in
Systemen und zum Reagieren auf diese geschaffen. Auf die Erkennung eines
Indikators für
einen wartungsbedürftigen
Zustand folgend wird eine Wartungsanforderung erzeugt und an einen
Wartungsdienstanbieter übertragen.
Die Wartungsanforderungen bewirken, dass eine Wissensbasis zu Rate
gezogen wird, die Informationen über
die Indikatoren, mögliche
Ursachen oder Zustände,
die zu den Indikatoren führen
könnten,
und Reaktionen auf die Zustände
enthält.
Danach können
automatisch Reaktionen erzeugt werden, um die Wartungsanforderungen
zu erfüllen.