DE102004015501A1 - Verfahren und Vorrichtung für Wartbarkeit komplexer Systeme - Google Patents

Verfahren und Vorrichtung für Wartbarkeit komplexer Systeme Download PDF

Info

Publication number
DE102004015501A1
DE102004015501A1 DE102004015501A DE102004015501A DE102004015501A1 DE 102004015501 A1 DE102004015501 A1 DE 102004015501A1 DE 102004015501 A DE102004015501 A DE 102004015501A DE 102004015501 A DE102004015501 A DE 102004015501A DE 102004015501 A1 DE102004015501 A1 DE 102004015501A1
Authority
DE
Germany
Prior art keywords
maintenance
concept
concepts
data
indicators
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102004015501A
Other languages
English (en)
Inventor
Rasiklal Punjalal Shah
Steven Hector Azzaro
Richard Lee Waukesha Frowein
Ernest Joseph Sussex Waldron
Stephen Robert Brookfield Crowley
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GE Medical Systems Inc
Original Assignee
GE Medical Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by GE Medical Systems Inc filed Critical GE Medical Systems Inc
Publication of DE102004015501A1 publication Critical patent/DE102004015501A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability

Abstract

Eine Wartbarkeitsstrategie ist geschaffen, die das Definieren mehrerer Wartungskonzepte (64) für Komponenten (38), Funktionen (38), Subsysteme (36) und vor Ort austauschbare Einheiten (40) in einem komplexen Maschinensystem (12), sowie die Durchführung/Implementierung der Konzepte ermöglicht, um auf auftretende servicebedürftige Ereignisse und Fehlfunktionen hin Wartungen auszuführen und die Konzepte im Laufe der Zeit zu verbessern. Die Konzepte (64) können in einer geeigneten Weise zugeordnet sein, so dass sie ausgewählt werden können, um auf erfassbare und eingrenzbare Ausgangsursachen von servicebedürftigen Ereignissen bei deren Auftreten anzusprechen, und die angemessenen Konzepte werden bei einem Auftreten derartiger Ereignisse auf der Basis vordefinierter Indikatoren (164) ausgewählt. Wenn im Laufe der Zeit Wartungsereignisse auftreten und durch Empfehlungen (184) angesprochen werden, die durch jeweilige Konzepte vorgeschlagen sind, werden Daten erfasst, die als die Grundlage für ein Weiterentwickeln der Konzepte dienen, um Ausgangsursachen von servicebedürftigen Ereignissen und Fehlfunktionen angemessener anzusprechen und die Wahl der Konzepte optimal anwendungsgemäß hinsichtlich eines Ansprechens von servicebedürftigen Ereignissen und Fehlfunktionen zu verbessern.

Description

  • HINTERGRUND ZU DER ERFINDUNG
  • Die vorliegende Erfindung betrifft ganz allgemein das Gebiet von Mechanismen zum Identifizieren von Fehlfunktionen und servicebedürftigen Bedingungen in komplexen Systemen. Insbesondere betrifft die Erfindung Techniken, um Ausfälle oder servicebedürftige Ereignisse besser zu erfassen, abzugrenzen und zu warten, und Wartbarkeitskonzepte zu verbessern, die verwendet werden, um Ausfälle und servicebedürftige Ereignisse zu erfassen und zu korrigieren.
  • Auf einem Gebiet komplexer Maschinensysteme wurden bisher vielfältige Techniken verwendet, die dazu dienen, Fehlfunktionen oder servicebedürftige Bedingungen zu erkennen und dieselben zu korrigieren. Frühe Techniken beschränkten sich auf ein einfaches manuelles Einschreiten. D.h. im Falle des Auftretens einer Fehlerbedingung oder eines Versagens führten Fachkräfte oder Wartungspersonal manuelle Problembehebungsmaßnahmen durch, um die mögliche Fehlerquelle zu identifizieren und die Fehlfunktion zu korrigieren. Solche Systeme eignen sich zwar im Allgemeinen für einfache Systeme, allerdings liefern sie keine besonders zuverlässige und erweiterbare Wartungsstrategie. Darüber hinaus hängen solche Ansätze vom Grad der Erfahrung, der Geschicklichkeit, der Intuition und dem Wissen von Technikern und Wartungspersonal ab, und damit von Voraussetzungen, die sowohl von Person zu Person als auch zeitabhängig stark variieren können.
  • Ansätze wurden unternommen, Fehlfunktionen und servicebedürftige Bedingungen auf reaktive und proaktive Weise analytischer und reproduzierbarer zu identifizieren. Allerdings bedienen sich die bestehenden Ansätze typischerweise nicht einer systematischen Strategie, die dazu dient, ein Konzept oder System einer Wartbarkeit zu errichten, das Konzept oder System zu implementieren und das Konzept und System nach einem Implementieren zu korrigieren. Es besteht daher großer Bedarf nach verbesserten Systemen, die in der Lage sind, eine Wartung in komplexen Systemen bereitzustellen. Ein besonderer Bedarf besteht nach einem Ansatz einer Gesamtstrategie einer Wartung, die übertragbar ist auf komplexe Maschinensysteme verschiedenster Art, die viele unterschiedliche Subsysteme, Komponenten, Funktionen, vor Ort austauschbare Einheiten, und so fort enthalten. Nach dem Stand der Technik wurde bisher noch kein umfassender Ansatz erfolgreich entwickelt, um Wartbarkeit zu entwerfen, zu implementieren und zu verbessern.
  • KURZBESCHREIBUNG DER ERFINDUNG
  • Es ist eine Technik geschaffen, die dazu dient, eine Strategie einer Gesamtwartungsstabilität für komplexe Maschinensysteme festzulegen, um auf solchen Bedarf zu reagieren. Das gesamte System und Verfahren lässt sich an vielfältige beliebige Maschinensysteme anpassen, einschließlich von Systemen, die Software, Hardware, Firmware, Maschinenelemente, und so fort verwenden. Das Gesamtsystem schließt die Erstellung einer Reihe von Wartungskonzepten für vielfältige Komponenten, Funktionen, Subsysteme und vor Ort austauschbare Einheiten ein, wobei jedes Konzept zum Erfassen und Eingrenzen gewisser, Elemente und Fehlermodi beiträgt. Die Konzepte werden an schließend implementiert und geeignet ausgewählt, um eventuell auftretende Wartungserfordernisse anzusprechen. Während die Konzepte im Laufe der Zeit in Reaktion auf servicebedürftige Ereignisse und Fehlfunktionen durchgeführt werden, wird durch eine Rückmeldung über tatsächliche Ergebnisse einer Wartung des komplexen Maschinensystems eine Verbesserung und Weiterentwicklung der Wartungskonzepte ermöglicht.
  • Die vorliegende Technik schafft ein Verfahren zum Definieren eines Wartungskonzepts für ein komplexes System. Ein Wartungskonzept wird für eine Komponente, eine Funktion, ein Subsystem oder eine vor Ort austauschbare Einheit eines komplexen Systems erzeugt, und das Konzept beinhaltet mehrere Fehlermodi und Indikatoren für die Fehlermodi. Das Wartungskonzept wird anschließend dazu verwendet, eine Wartungsmaßnahme zu empfehlen, die sich eines servicebedürftigen Ereignisses auf der Grundlage der Indikatoren und Eingabedaten aus dem komplexen System annimmt. Das Wartungskonzept wird anschließend auf der Basis von ausgeführten Wartungsmaßnahmen bewertet.
  • Die Technik schafft ferner ein Verfahren zum Definieren eines Wartungskonzepts, mit dem Schritt des Erzeugens mehrerer Wartungskonzepte für unterschiedliche Komponenten, Funktionen, Subsysteme oder vor Ort austauschbare Einheiten. Jedes Wartungskonzept beinhaltet mehrere Fehlermodi und Indikatoren für die Fehlermodi für entsprechende Komponenten, die Funktion, das Subsystem oder die vor Ort austauschbare Einheit. Auf der Grundlage der Indikatoren und Eingabedaten aus dem komplexen System wird aus den vielen Wartungskonzepten eines ausgewählt. Das ausgewählte Wartungskonzept wird verwendet, um eine Wartungsmaßnahme zu empfehlen, die sich eines servicebedürftigen Ereignisses auf der Grundlage der Indikatoren und Eingabedaten aus dem komplexen System annimmt. Das ausgewählte Wartungskonzept wird anschließend auf der Grundlage der ausgeführten Wartungsmaßnahmen bewertet.
  • Gemäß einem weiteren Aspekt der Technik, umfasst ein Verfahren zum Definieren eines Wartungskonzepts die Erzeugung eines Wartungskonzepts für eine Komponente, eine Funktion, ein Subsystem oder eine vor Ort austauschbare Einheit eines komplexen Systems. Das Wartungskonzept beinhaltet mehrere Fehlermodi, Indikatoren für die Fehlermodi und eine Angabe über Kosten von Wartungsmaßnahmen im Zusammenhang mit dem jeweiligen Fehlermodus. Für jeden Fehlermodus wird eine empfohlene Wartungsmaßnahme erstellt, die zumindest auf den jeweilig zugewiesenen Kostenfaktor begründet ist. Das Wartungskonzept wird verwendet, um auf der Grundlage der Indikatoren, der Kosten und der Eingabedaten aus dem komplexen System eine Wartungsmaßnahme für ein servicebedürftiges Ereignis zu empfehlen. Das Wartungskonzept wird auf der Grundlage ausgeführter Wartungsmaßnahmen bewertet.
  • Die Erfindung schafft ferner Systeme und Rechnerprogramme, die geeignet sind, ähnliche Funktionalitäten durchzuführen, wie sie oben im Zusammenhang mit den vielfältigen Verfahren erwähnt sind.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die oben erwähnten und andere Vorteile und Merkmale der Erfindung erschließen sich nach dem Lesen der nachfolgenden detaillierten Beschreibung in Verbindung mit den Zeichnungen:
  • 1 zeigt eine schematische Veranschaulichung eines Wartungssystems, das dazu dient, die Konzeption gewisser Fehlerbedingungen oder Ereignisse in einem komplexen Maschinensystem gemäß Aspekten der vorliegenden Technik zu ermöglichen;
  • 2 zeigt eine schematische Veranschaulichung gewisser funktioneller Komponenten des Systemabschnitts des Konzeptentwurfs und der Konzeptimplementierung des in 1 veranschaulichten gesamten Wartungssystems;
  • 3 zeigt eine schematische Veranschaulichung gewisser funktioneller Komponenten in einem Entwicklungs- und Analysesystemabschnitt des in 2 veranschaulichten Systems;
  • 4 zeigt eine schematische Veranschaulichung eines Konzeptwahlsystems, das dazu dient, einem komplexen Maschinensystem Wartung zukommen zu lassen;
  • 5 zeigt eine schematische Veranschaulichung gewisser funktioneller Komponenten in einem Konzeptanalyse- und Bewertungsmodul, die dazu dienen, die Leistung des Gesamtsystems und der durch das System verwendeten Konzepte zu bewerten und zu verbessern;
  • 6 zeigt eine Darstellung eines exemplarischen Interface zum Entwerfen eines Konzepts für eine Wartung gemäß den in 3 zusammengefassten Komponenten;
  • 7 zeigt ein weiteres exemplarisches Interface zum Entwerfen des Konzepts in einer alternativen Weise, das in Verbindung mit jenem nach 6 verwendet werden kann;
  • 8 zeigt eine exemplarische Ausführung eines Analysedatenblatts zum Auswerten eines Wartungskonzepts während einer Entwurfsphase;
  • 9 zeigt eine exemplarische Ausführung eines analytischen Diagnosetools, das verwendet wird, um Wartungskonzepte während der Gültigkeitsprüfungs- und diagnostischen Phasen zu auswerten;
  • 10 zeigt eine exemplarische Darstellung eines Wartungsrückmeldungsdatenblatts, das eine Übersicht über die Effizienz und Genauigkeit spezieller Konzepte und über die auf der Grundlage der Konzepte vorgeschlagenen Wartungsempfehlungen bereitstellt; und
  • 11 zeigt ein Datenblatt ähnlich wie jenes in 10, das jedoch zusätzliche Einzelheiten hinsichtlich einzelner Ereignisse angibt, die eine Wartung hervorriefen, auf der das Datenblatt beruht.
  • AUSFÜHRLICHE BESCHREIBUNG SPEZIELLER AUSFÜHRUNGSBEISPIELE
  • Indem nun beginnend mit 1 auf die Zeichnungen eingegangen wird, ist ein Wartungssystem 10 zum Ermitteln von Leistung und zum Bereitstellen von Empfehlungen und Wartung für ein komplexes Maschinensystem 12 schematisch veranschaulicht. In der vorliegenden Erörterung wird durchweg Bezug genommen auf ein Maschinensystem 12 und die Wartung eines derartigen Maschinensystems. Viele unterschiedliche Gebiete können Nutzen aus Aspekten der vorliegenden Technik ziehen, jedoch eignet sich die Technik besonders gut zum Bewerten von wie nachstehend beschriebenen Funktionen und Komponenten eines komplexen Maschinensystems, einschließlich von Systemen, Subsystemen, vor Ort austauschbaren Einheiten, und so fort. Selbstverständlich ist mit dem Begriff eines komplexen Maschinensystems keine Beschränkung der vorliegenden Technik auf herkömmliche mechanische Geräte beabsichtigt, obwohl solche Geräte und Systeme selbstverständlich durch die vorliegenden Techniken bewertet und gewartet werden können. Vielmehr sollte der Begriff in dem Sinne verstanden werden, dass beliebige komplexe Systeme von Komponenten, Funktionen, Subsystemen, vor Ort austauschbaren Einheiten, sowohl stationärer als auch mobiler Natur, und auf Hardware, Software, Firmware, oder in sonstiger Weise gestützt einzubeziehen sind. An manchen Stellen der vorliegenden Erörterung wird beispielsweise auf Bildgebungssysteme Bezug genommen, wie sie beispielsweise im Zusammenhang mit medizinischen Diagnostiken verwendet werden. Wie dem Fachmann klar ist, enthalten derartige Systeme zahllose Subsysteme und Komponenten, die ihre Funktion innerhalb gewisser Parameter erfüllen sollten, um die gewünschte Funktionalität zu erfüllen. Im Zusammenhang mit medizinischen Diagnostiken werden beispielsweise Systeme unterschiedlicher Modalität verwendet, z.B. Magnetresonanzbildgebungssysteme, Computertomographiesysteme, röntgenologische Systeme, Ultraschallsysteme, Positronenemissionstomographiesysteme, und so fort. Diese und andere Systeme können gemäß der vorliegenden Techniken konzipiert und gewartet werden, um deren Funktionalität und Bedienbarkeit aufrecht zu erhalten.
  • Wie weiter unten eingehender beschrieben, umfasst das System 10 ein mit dem Bezugszeichen 14 bezeichnetes System zum Entwerfen und Durchführen von Konzepten. Das System zum Entwerfen und Durchführen von Konzepten ermöglicht die Entwicklung von speziellen Wartungskonzepten für das komplexe Maschinensystem und dessen Subsysteme. Wie auch weiter unten eingehender beschrieben, können die Konzepte auf Vollständigkeit, Genauigkeit, Reproduzierbarkeit, Erfassbarkeit gewisser Fehlermodi und so fort überprüft werden. Das System 14 zum Entwerfen und Durchführen von Konzepten ermöglicht ferner eine tatsächliche Durchführung der entwickelten Wartungskonzepte. Während einer derartigen Durchführung werden durch vielfältige Mittel, sei es automatisiert oder manuell, Daten erfasst, und ein oder mehrere Wartungskonzepte werden automatisch ausgewählt, um empfohlene Maßnahmenabläufe für ein Bereitstellen einer Wartung für die identifizierten Systeme, Subsysteme, Komponenten oder Funktionalitäten zu ermitteln. Das System 14 ermöglicht auch eine periodische Analyse über die Lebensdauer des Systems hinweg, um die Effizienz des implementierten Wartungskonzepts zu bewerten. D.h. in dem Maße wie detailliertere oder empirische Daten hinsichtlich der für das System erforderlichen Wartung verfügbar werden, werden solche Daten in die Konzepte integriert, um deren Genauigkeit und Leistung hinsichtlich einer Vorhersage und eines Reagierens auf servicebedürftige Bedingungen und Ereignisse während deren Auftreten oder im Vorfeld zu verbessern.
  • Das komplexe Maschinensystem 12 wird über ein Datenerfassungsmodul betreut, das in beliebiger geeigneter Form vorliegen kann. Ganz allgemein kann das Datenerfassungsmodul 16 Software, Hardware oder Firmware enthalten, die automatisch oder manuell die für eine Analyse des Betriebszustands des Maschinensystems erforderlichen Datenwerte, Parameterwerte, Ereignisprotokolle, und so fort sammeln. Das Datenerfassungsmodul kann derartige Daten in Echtzeit, periodisch während eines automatisch oder manuell initiierten Datendurchlaufs, oder in jeder sonstigen geeigneten Weise sammeln. Die gesammelten Daten können in einem Memorymodul 18 gespeichert werden. Sowohl das Datenerfassungsmodul 16 als auch das Memorymodul 18 können sich in örtlicher Nähe des Maschinensystems 12 oder an einem oder mehreren entfernt angeordneten Standorten befinden. Das Datenerfassungsmodul ist an ein Kommunikationsmodul 20 angeschlossen, das eine Übertragung von Daten zu und von dem Datenerfassungsmodul, und damit zu und von dem Memorymodul 18 und dem komplexen Maschinensystem 12 vereinfacht. Das Kommunikationsmodul 20 kann eine oder mehrere unterschiedliche Arten von Datenübertragungsmitteln enthalten und kann nach jedem gewünschten Protokoll, z.B. Internetprotokollen arbeiten. Dementsprechend kann das Kommunikationsmodul 20 Router, Server, Firewalls, Sicherungseinrichtungen und beliebige sonstige gewünschte Schaltkreise enthalten, die der Übertragung und Sicherheit der zu übertragenen Daten dienen. Ein Netzwerk 22 vereinfacht einen Austausch der Daten zwischen dem Kommunikationsmodul 20 und dem Konzeptentwurfsimplementierungssystem 14.
  • Das Konzeptentwurfsimplementierungssystem 14 kann an einem oder mehreren Standorten eine Reihe von Rechnerressourcen und Schaltkreisen enthalten. Insbesondere sollte es klar sein, dass das System 14 einen weiten Bereich von Funktionalität sowohl hinsichtlich des Entwerfens, des Testens, des Implementierens als auch der eventuellen Bewertung und Verfeinerung von Wartungskonzepten ermöglicht. Während bestimmte Systeme und Module hier schematisch oder analytisch beschrieben sind, wird es dem Fachmann daher einleuchten, dass diese Module viele darin eingebettete Routinen und Funktionen aufweisen können, von denen einige hier beschrieben und in der Lage sind, diese Funktionen in mannigfaltiger Form über Netzwerke, an lokalen Workstations, durch interaktives Verarbeiten von Ressourcen und so fort durchführen können.
  • Wie in 1 zu sehen, enthält ein System 14 zum Entwerfen und Durchführen von Konzepten ein Analyse/Wartungsmodul 24, das über ein Netzwerk 22 von dem Maschinensystem 12 Daten empfängt. Das Modul 24, das seinerseits gegebenenfalls vielfältige Softwareroutinen und Hardware- oder Firmwareschaltkreise enthält, dient dazu, die empfangenen Daten zu analysieren und eine Übertragung von Daten anzufordern, die für die von dem System auszuführenden Funktionen der Konzeptentwicklung, Konzeptdurchführung und Konzeptverfeinerung benötigt werden. Das Modul 24 ist mit einem Entwicklungs-/Analyse-System 26 verbunden, das dazu dient, die Entwicklung von Wartungsmodulen für das Maschinensystem und deren Analyse und Verfeinerung zu unterstützen. Vielfältige Berichtsmodule, die weiter unten eingehender beschrieben und in 1 allgemein mit dem Bezugszeichen 28 bezeichnet sind, dienen dazu, während sämtlicher Betriebsphasen des Systems 14 Berichte zu erstellen. Die Berichtsmodule stellen beispielsweise Berichte über Analysen bereit, die an gewissen Konzepten während der Entwurfsphasen durchgeführt wurden, sowie Berichte und Empfehlungen für eine Wartung während der aktuellen Durchführung der Konzepte. Darüber hinaus können die Berichtsmodule 28 Berichte vorsehen, die die tatsächliche Leistung der Konzepte über die Zeit hinweg basierend auf einer tatsächlichen Wartung des Systems kennzeichnen. Diese und andere Berichte können periodisch durch das System oder auf Benutzeranforderungen hin bereitgestellt werden. Das Modul 24, das System 26 und die Berichtsmodule 28 können mit einer Datenbank 30 oder einer beliebigen sonstigen geeigneten Speichereinrichtung verbunden sein. Während die Datenbank 30 in 1 für veranschaulichende Zwecke dargestellt ist, werden die Systeme und Module für eine tatsächliche Durchführung im Allgemeinen jeweils gesonderte Arbeitsspeicher zum Ausführen ihrer Funktionen, zum Speichern von Parametern und Daten, zum Speichern von Konzepten, zum Speichern von Wartungsaufforderungen, zum Speichern von Wartungsempfehlungen und Wartungsvorgeschichten etc. enthalten. Solche Arbeitsspeicher können von beliebiger geeigneter Bauart sein, und es können weitere Arbeitsspeicher und Datenbanken in einer verknüpften Weise vorgesehen sein, um den Austausch der Daten, das Archivieren von Daten, und so fort zu unterstützen. Bei einer tatsächlichen Durchführung werden beispielsweise häufig typischerweise eine Anzahl unterschiedlicher Arbeitsspeicherstandorte zur Verfügung stehen, die Software und Daten zum Durchführen der vielfältigen unten beschriebenen individuellen Funktionen speichern. Es wird ferner die Möglichkeit in Betracht gezogen, derartige Arbeitsspeicher zu verknüpfen oder redundant zu gestalten, um einige der hier beschriebenen funktionellen Komponenten und Funktionalitäten online oder offline betreiben zu können. Dementsprechend ist eine Workstation 32, wie in 1 dargestellt, mit dem Entwicklungs-/Analyse- System 26 verbunden und enthält, wie herkömmlich üblich, einen Rechner, einen Monitor, Eingabegeräte, Ausgabegeräte, und so fort. Ähnliche, allgemein mit dem Bezugszeichen 34 bezeichnete Workstations können mit dem System 26, dem Modul 24, den Berichtsmodulen 28 und sonstigen Komponenten verbunden sein, die für einzelne Clients oder Workstations in dem System zum Entwerfen und Durchführen von Konzepten 14 vorgesehen sind.
  • Wie oben erwähnt, kann das komplexe Maschinensystem 12 eine große Anzahl von Komponenten und Funktionen, sowie Subsystemen, vor Ort austauschbaren Einheiten, und so fort enthalten. Einige dieser Merkmale sind in 1 veranschaulicht. In dem veranschaulichten System 12 enthält ein Subsystem 36 vielfältige Komponenten oder Funktionen 38. Die Komponenten oder Funktionen umfassen jeweils vor Ort austauschbare Einheiten 40. Es ist zu beachten, dass der Begriff vor Ort austauschbare Einheit in dem hier verwendeten Sinne vielfältige Komponenten oder Teile, sowie Zusammenstellungen von Komponenten oder Teilen beinhalten kann, die in der Lage sind, entweder in Zusammenwirken miteinander oder bis zu einem gewissen Grade getrennt nützliche Funktionen auszuführen. Wie für den Fachmann offensichtlich, kann gewünschtenfalls eine beliebige Anzahl von Subsystemen in komplexen Systemen durch ihre Funktionalität, Interdependenz, gesonderte Fähigkeit der Herstellung oder Wartung und so fort festgelegt werden, was gewöhnlich auch der Fall ist. In ähnlicher Weise können vor Ort austauschbare Einheiten geeignet konstruiert sein, um eine Wartung durch einfaches Austauschen integrierter Teile, Programmroutinen und so fort zu erleichtern. Wie weiter unten eingehender beschrieben, ermöglicht ein Aspekt der vorliegenden Technik den Entwurf oder die Zuordnung vor Ort austauschbarer Einheiten gemäß der Erfassbarkeit oder Eingrenzung von War tungs- oder Fehlerbedingungen, Kosten von Elementen, die gewartet oder einfach ausgetauscht werden können und so fort.
  • Einige Komponenten oder Funktionen des Systems 10 sind jedoch möglicherweise nicht in zugeordneten vor Ort austauschbaren Einheiten oder auch in festgelegten Subsystemen, Komponenten oder Funktionen vorhanden. In 1 sind zusätzliche vor Ort austauschbare Einheiten dargestellt, die sich außerhalb der logischen Zuordnung des Subsystems 36 befinden und in keiner der speziellen Komponenten oder Funktionen vorkommen. Obwohl nicht eigens in 1 veranschaulicht, können in ähnlicher Weise vor Ort austauschbare Einheiten von einzelnen Subsystemen etc. getrennt sein. Es sollte beachtet werden, dass vielfältige vor Ort austauschbare Einheiten, Komponenten und Funktionen, Subsysteme und so fort an einem oder mehreren physischen Standorten vorhanden sein können. D.h. das System 12 ist nicht auf einen speziellen physischen Standort beschränkt, sondern kann zugeordnete Komponenten, Funktionen, Subsysteme und so fort an vielfältigen unterschiedlichen Standorten einschließen.
  • Die Komponenten und Funktionen des Systems 12 sind eingerichtet, um Daten zu erfassen, die dazu nutzbar sind, um den Betriebszustand des Systems zu identifizieren und Fehlerbedingungen zu identifizieren und zu diagnostizieren. Die wie oben erwähnt gesammelten Daten werden in Verbindung mit Wartungskonzepten für die einzelnen Komponenten oder Funktionen oder mit Konzepten für vor Ort austauschbare Einheiten oder auch mit Subsystemen verwendet. Zunächst werden die Daten jedoch für einen Einsatz der Konzepte erfasst oder gesammelt. Diese Funktion kann in vielfältiger Weise ausgeführt werden und wird in vielfältiger Weise an unterschiedlichen Einzelkomponenten und -funktionen des Systems ausgeführt.
  • In dem in 1 veranschaulichten Ausführungsbeispiel sind für die vielfältigen vor Ort austauschbaren Einheiten 40 Sensoren 42 vorgesehen. Die Art der Sensoren wird selbstverständlich von der Art der einzelnen zu erfassenden Parameter abhängen. Im allgemeinen werden Parameter erfasst, die eine Auskunft über den operativen Zustand der einzelnen Komponente oder Funktion beinhalten. Diese Aufgabe kann von einem oder mehreren Sensoren durchgeführt werden, und die Sensoren können eigens dieser Aufgabe zugewiesen sein oder ganz allgemein eine operative Funktion innerhalb des Systems erfüllen. Beispielsweise können an den Komponenten speziell zugewiesene Transducer vorgesehen sein, die dazu dienen, Parameter wie Stromstärke, Spannung, Temperatur, Geschwindigkeit, Schwingung, chemische Eigenschaften oder sonstige andere operative Parameter zu erfassen. Indikatoren für einen operativen Zustand von Software werden ebenfalls als Sensoren im Zusammenhang mit der vorliegenden Erfindung in Betracht gezogen. Wo es geeignet erscheint, können die Sensoren bereits vorgesehen sein, um derartige für den normalen Betrieb des Systems nützliche Funktionen zu erfüllen. In Fällen, wo derartige Parameter benötigt werden und nicht durch die bestehenden Systemkomponenten zur Verfügung stehen, ermöglicht die vorliegende Technik ein Hinzufügen solcher Sensoren, um die durch die Wartungskonzepte ermöglichten Fähigkeiten der Erfassbarkeit und Eingrenzung zu verbessern. Während die Sensoren als FRUs 40 zugeordnet veranschaulicht sind, ist jedoch ferner zu beachten, dass derartige Sensoren allgemeiner auf vielfältigen Ebenen in dem System vorgesehen sein können, beispielsweise auf Ebenen von Komponenten oder Funktionen, Subsystemebenen und so fort.
  • Wie weiter unten eingehender beschrieben, lassen sich gewisse Parameter oder Überwachungen nicht ohne Weiteres automatisiert durchführen. Solche Eingaben verlangen gegebenenfalls vielmehr ein menschliches oder spezielles maschinelles Eingreifen für Erfassungszwecke. Zwei der in 1 dargestellten vor Ort austauschbaren Einheiten 40 (siehe FRU8 und FRU9) sind nicht mit Sensoren ausgerüstet, sondern benötigen eine derartige manuelle oder halbautomatische Rückmeldung. Die in 1 veranschaulichten Sensoren 42 sind dementsprechend gezeigt, wie sie dem Datenerfassungsmodul 16 über beliebige geeignete Datenübertragungskanäle 44 Daten zur Verfügung stellen, während gestrichelte Linien 46 schematisch veranschaulichen, dass gewisse Daten oder Überwachungen auf solche manuelle oder halbautomatische Weisen übermittelt werden können. Ferner ist zu beachten, dass auch auf Abruf zu startende Diagnosetests und Diagnoseroutinen Indikatordaten für eine Verwendung durch die Konzepte zur Verfügung stellen können. Wie dem Fachmann klar, können viele Systeme mit solchen Programmroutinen ausgerüstet sein, die sich durch einen Benutzer initiieren lassen, um den Betriebszustand des Systems oder der Einzelkomponenten des Systems zu ermitteln, indem Parameterdaten in Echtzeit und/oder aus Ereignisprotokollen und dergleichen gesammelt und überdies analysiert werden. In ähnlicher Weise kann eine Wartungsworkstation 48 oder eine ähnliche Schnittstelleneinrichtung mit dem System verbunden sein, um Daten und Überwachungen bereitzustellen, die als Indikatoren dienen können, die in den vielfältigen nachstehend erörterten Wartungskonzepten verwendet werden. Solche Workstations 48 können ferner dazu dienen, eine Wartung anzufordern, Konzepte zusammenzustellen oder zu verfeinern, Berichte und Wartungsempfehlungen entgegenzunehmen oder anzufordern und so fort.
  • 2 veranschaulicht gewisse funktionelle Komponenten des oben erörterten Systems 14 zum Entwerfen und Durchführen von Konzepten. Insbesondere sind Komponenten des Entwicklungs/Analyse-Systems 26 sowie Komponenten des Analyse/Wartungsmoduls 24 veranschaulicht. Diese Komponenten sind dargestellt, wie sie ausgerüstet sind, um miteinander und mit einem Konzeptverfeinerungsmodul 50 Daten auszutauschen. Wie weiter unten eingehender erörtert, ermöglicht das Konzeptverfeinerungsmodul 50 basierend auf tatsächlicher Wartungserfahrung für das komplexe Maschinensystem eine Verfeinerung der Wartungskonzepte.
  • Das Entwicklungs-/Analyse-System 26, das Komponenten verwenden kann, die in einem vorliegenden Ausführungsbeispiel als ein Kausalitätsmotor beschrieben sind, erleichtert ein Autorisieren von Konzepten, ein Definieren von Konzepten und deren Verfeinerung bevor diese implementiert werden. Im Allgemeinen stellt eine Autorisierungsmodul 52 zur Unterstützung des aktuellen Entwurfs eines Wartungskonzepts Software und Interfaces bereit, die in der Lage sind, operative Bedingungen einer oder mehrerer Komponenten oder Funktionen des Maschinensystems während des Betriebs auszuwerten. Das Autorisierungsmodul 52 ist mit einem Konzepterzeugungsmodul 54 verbunden, das Software zum aktuellen Kompilieren des Wartungskonzepts benötigt. Das Konzepterzeugungsmodul 54 ist wiederum mit einem Konzeptentwurfsanalysemodul 56 verknüpft, das dazu dient, das Modul, wie weiter unten eingehender beschrieben, hinsichtlich einer Erfassbarkeit und Eingrenzung gewisser Fehlfunktionen oder Fehlermodi zu analysieren. Die Module 52, 54 und 56 arbeiten im Allgemeinen auf der Grundlage einer Systemdefinition, die allgemein mit dem Bezugszeichen 58 bezeichnet ist. Die Systemde finition kann Güteanforderungen oder Definitionen einzelner vor Ort austauschbarer Einheiten, Komponenten, Funktionen, Subsysteme und so fort enthalten, die sowohl aktuell in einem Maschinensystem als auch in Planungsphasen implementiert werden. Wie weiter unten eingehender beschrieben, fördern die Module des Entwicklungs-/Analyse-Systems 26 das Planen und Entwerfen sowohl der Wartungsmodule als auch der Verbesserungen des aktuellen Systems. D.h. in Fällen, in denen sich gewisse Fehlfunktionen oder Bedingungen nicht eindeutig erfassen oder eingrenzen lassen, können zusätzliche Sensoren oder Indikatoren zugewiesen und vorgesehen werden.
  • Das Analyse/Wartungsmodul 24 führt die durch das System 26 entwickelten Wartungskonzepte effizient durch. Im Wesentlichen enthält das Modul 24 ein Indikatoranalysemodul 60, das Daten entgegennimmt und analysiert. Da die Daten ein sehr großes Array (Feld) von Datenpunkten, Werten, Bereichen, Zählerständen, und so fort enthalten können, ist ein flexibler Konzeptwahlmodul 62 vorgesehen, der ein oder mehrere Konzepte für eine Analyse zum Ermitteln des eventuell erforderlichen Bedarfs für eine Wartung auswählt. Wie weiter unten eingehender beschrieben, ermöglicht das Modul 62 nicht nur die Wahl eines oder mehrerer Konzepte, und dadurch ein Fokussieren auf ein oder mehrere Subsysteme, Komponenten oder Funktionen, vor Ort austauschbare Einheiten, und so fort, sondern ermöglicht darüber hinaus ein periodisches Aktualisieren oder Verändern von Kriterien, die für eine Wahl des einen oder der mehreren Konzepte verwendet werden. Auf der Grundlage des Betriebs des Moduls 62 werden anschließend ein oder mehrere Konzepte 64 für eine Analyse und zum Ermitteln von Empfehlungen des Systems ausgewählt. Im Vergleich zu dem System 26, das im Allgemeinen basierend auf einer Systemdefinition 58 arbeitet, arbeiten die Module und Konzepte des Moduls 24 auf der Basis von Daten eines im Betrieb befindlichen Systems, wie es in 2 allgemein mit dem Bezugszeichen 66 bezeichnet ist.
  • Wie weiter unten eingehender beschrieben, dient das Konzeptverfeinerungsmodul 50, das ebenfalls auf der Basis von Daten eines aktuell im Betrieb befindlichen Systems 66 arbeitet, dazu, die Gültigkeit, Genauigkeit und die Gesamtperformance eines oder mehrerer einzelner Konzepte zu ermitteln. D.h. auf der Basis aktueller Ereignisse und an dem System durchgeführter Wartung, können die mittels des Systems 26 entwickelten und durch das Modul 24 implementierten Konzepte verfeinert werden, um eine verbesserte Funktionalität, reduzierte Kosten, größere Zuverlässigkeit, verbesserte Erfassbarkeit und Eingrenzung von Fehlfunktionen oder servicebedürftigen Bedingungen und so fort zu ermöglichen.
  • Die allgemeinen Komponenten in 2, die als in dem Entwicklungs-/Analyse-System 26 enthalten veranschaulicht sind, werden in 3 detaillierter dargestellt. Auch hier kommt das Entwicklungs-/Analyse-System in der Gesamtkonfiguration eines Konzipierens/Modellierens der Wartung und Bereitstellung von Wartungsvorgängen in einem vorliegenden Ausführungsbeispiel während der frühen Stadien einer Konzeptentwicklung in Anwendung und bleibt während der aktuellen Implementation/Durchführung des Wartungskonzepts aktiv. Das Autorisierungsmodul 52 sieht vielfältige Arten von Interfaces vor, die von Konstrukteuren, Entwicklern, Wartungstechnikern und Wartungspersonal zum Analysieren und Entwerfen sowohl der Wartungskonzepte als auch des komplexen Maschinensystems selbst verwendet werden können, um ein Erfassen, Eingrenzen und Warten von Fehlfunktionen und servicebedürftigen Ereignissen zu erleichtern. Insbesondere sind in einem vorliegenden Ausführungsbeispiel zwei unterschiedliche Interfaces in dem Autorisierungsmodul 52 vorgesehen. Diese enthalten eine erweiterte Fehlermoduseffektanalyse (FMEA), die in Form einer verhältnismäßig unkomplizierten und leicht zu begreifenden Rechnerschnittstelle und Unterstützungssoftware vorliegt, um einzelne Aspekte des Wartungskonzepts definieren zu können. Wie weiter unten anhand von 6 eingehender beschrieben, erlaubt das erweiterte FMEA-Interface 68 beispielsweise das System, das Subsystem, die Komponente und vielfältige sonstige Elemente, Fehlermodi, Wartungsmaßnahmen und den Elementen oder Fehlermodi entsprechende Indikatoren zu definieren. In ähnlicher Weise können ein oder mehrere zusätzliche Interfaces vorgesehen sein, beispielsweise ein Fehlerindikator- und Wartungsmaßnahmen-(FISA)-Interface. Dieses Interface oder andere Interfaces, eignet sich besonders dazu, ein anderes Format vorzusehen, um Daten einzugeben, die jenen ähneln, die in dem erweiterten FMEA-Interface 68 anzutreffen sind. In der Tat erlauben in dem vorliegenden Ausführungsbeispiel beide Interfaces eine Definition derselben Daten, und stellen einfach andere Formate bereit, die von unterschiedlichen Benutzern leichter zu begreifen und zu verwenden sind.
  • Ein Interfaceübersetzungsmodul 72 ermöglicht den Austausch von Daten zwischen den Interfaces 68 und 70. Da über jedes Interface gleiche oder ähnliche Daten eingegeben werden, können diese Daten insbesondere, abhängig von der verfügbaren Information oder den Präferenzen des Benutzers, über das jeweilig andere Interface angezeigt und interaktiv bedient werden. Das Interfacemodul tauscht anschließend Daten mit dem Konzeptdefinitionsmodul 74 aus. Das Konzeptdefinitionsmodul nutzt eine Modellierungssoftware 76, die im Handel erhältlich ist, um beispielsweise spezielle Typen von Konzepten zusammenzustellen. In einem vorliegenden Ausführungsbeispiel implementiert das Konzeptdefinitionsmodul 74 auf der Grundlage von Daten, deren Eingabe und Zugriff über die mittels des Interfaceübersetzungsmoduls 72 koordinierten Interfaces 68 und 70 erfolgt, Software zum Definieren eines Bayesianischen Netzwerks. Eine derartige Software ist im Handel aus vielfältigen Quellen, z.B. von Hugin Expert A/S in Dänemark, erhältlich.
  • Wie weiter unten anhand von 6 und 7 näher erläutert, in denen die Interfaces 68 und 70 veranschaulicht sind, ist ein Bereich von Daten für die Definition jedes Konzepts vorgesehen. In einem vorliegenden Ausführungsbeispiel sind ausreichende Einzelheiten und Definitionen vorgesehen, um Fehlfunktionen oder servicebedürftige Ereignisse in einzelnen vor Ort austauschbaren Einheiten, Komponenten oder Funktionen, oder in einzelnen servicebedürftigen Subsysteme zu erfassen und einzugrenzen. D.h. auf der Ebene eines Konzepts erlauben einzelne Konzepte, die jedoch einen gewissen Grad von Wechselbeziehung oder Interdependenz aufweisen, eine vor Ort austauschbare Einheit, Komponente, ein Funktion, Subsystem, oder dgl. zu identifizieren, die bzw. das sich am besten als Ziel eignet, um einen speziellen Wartungsbedarf anzusprechen, während ein solcher entsteht.
  • Die Zusammenstellung von mittels des Konzeptautorisierungsmoduls 52 entworfenen Konzepten stellt eine Bibliothek von Modulen dar, beispielsweise ein Bayesianisches Netzwerkmodell 54. Es ist zu beachten, dass das hier beschriebene Bayesianische Netzwerk einem speziellen Fall des Konzepterzeugungsmoduls 54 in 2 entspricht. Obwohl das veranschaulichte Bayesianische Netzwerk in dem vorliegenden Ausführungs beispiel bevorzugt ist, können in der Tat vielfältige andere Arten von Konzepten, Netzwerken und dergleichen verwendet werden. Wie dem Fachmann klar, stellen Bayesianische Netzwerke gewisse Einrichtungen und Vorteile, z.B. die Fähigkeit, potentielle Ereignisse und deren Ursachen zu identifizieren sowie statistische Voraussagen oder Korrelationen zwischen vielfältigen Ereignissen und Ursachen zu treffen, zur Verfügung.
  • Das Konzeptentwurfsanalysemodul 56 dient dazu, die Leistung jedes Konzeptes zu bewerten, das durch den Autorisierungsmodul 52 entwickelt wurde und vor einer Anwendung einen Teil des Moduls 54 bildet. Insbesondere das Entwurfsanalysemodul 56 erleichtert es zu ermitteln, ob ein spezieller Fehlermodus, Ereignisse, servicebedürftige Bedingungen und dergleichen sich erfassen und voneinander abgrenzen lassen. Um die effizienteste Wartung des komplexen Systems zu erreichen, ist es erwünscht, dem Wartungssystem zu ermöglichen, den Fehlerort vielfältiger servicebedürftiger Ereignisse oder Fehlfunktionen zu erfassen, und Wartungssysteme oder Wartungspersonal zielsicher und rasch auf derartigen Ursachen aufmerksam zu machen. Die Analyse der Ursache und die Ermittlung der Empfehlung können allerdings auf vielfältigen Kriterien begründet sein, z.B. einer Minimierung der Ausfallzeit, Kostenminimierung, und so fort. Der Konzeptentwurfsanalysemodul 56 erleichtert auf diesen Grundlagen ein Bereitstellen einer Rückmeldung über die Effizienz der Konzepte. Ein Analysedatenblattmodul 78 dient daher dazu, ein Datenblatt oder einen Bericht einer derartigen Analyse zu erstellen. In ähnlicher Weise dient ein diagnostisches oder Gültigkeitsprüfungskonzeptmodul 82 dazu, eine Antwort des Konzepts auf servicebedürftige Ereignisse zu simulieren und gewisse Probleme oder Bereiche hinsichtlich einer Verbesserung des Konzepts zu untersuchen. In einer vorliegenden Ausführung erzeugt das Analysedatenblattmodul 78 dann ein Datenblatt 84, während das Diagnose- oder Gültigkeitsprüfungsmodul 82 einen Gültigkeitsprüfungsbericht 86 erzeugt. Auf das Datenblatt 84 und den Gültigkeitsprüfungsbericht 86 wird weiter unten mit Bezug auf 8 und 9 näher eingegangen.
  • Das Entwicklungs-/Analyse-System 26 dient dazu, das Wartungskonzept für ein oder mehrere Komponenten oder Funktionen des komplexen Maschinensystems 12 zu errichten. Anschließend an eine solche Entwicklung implementiert das Wartungssystem 10 jedoch die Konzepte hinsichtlich einer Echtzeit- oder periodischen Analyse eines Wartungsbedarfs bei dessen Auftreten oder auf der Grundlage einer Prognose. 4 repräsentiert schematisch eine derartige Implementierung in einem vorliegenden Ausführungsbeispiel. Wie in 4 gezeigt, stellt das komplexe Maschinensystem 12 Daten bereit, die den Betriebszustand der vielfältigen Komponenten und Funktionen betreffen, wie er durch Sensoren 42 erfasst wird oder durch manuelle oder Benutzerkommunikationsmittel 46 angegeben wird. Im Allgemeinen werden die von dem System bereitgestellten Daten vielfältige Indikatoren definieren, die spezielle vor Ort austauschbare Einheiten, Komponenten, Funktionen, Subsysteme und so fort identifizieren, die fehlerhaft arbeiten oder einer gegenwärtigen oder zukünftigen Wartung bedürfen. Wie weiter unten gemäß der in 6 und 7 gezeigten erweiterten FMEA- und FISA-Interfaces eingehender beschrieben, kann ein breiter Bereich von Elementen und Fehlermodi in diese Weise identifiziert werden. Bei der Entwicklung der Konzepte, wird angestrebt, eine Erfassbarkeit der vielfältigen Fehlermodi sowie die Fähigkeit zu erlangen, einzelne Komponenten, Funktionen, Subsysteme oder vor Ort austauschbare Einheiten, die wahrscheinlich ein Auslösen der Fehlermodi verursacht haben, einzugrenzen. Im Ideal fall ist jeder Fehlermodus eindeutig identifizierbar und die Ursache der Fehlermodi kann eingegrenzt werden, um spezielle Empfehlungen für eine Wartung vorzusehen. Eine solche Wartung kann abhängig von der Art der vor Ort austauschbaren Einheit, der Komponente, der Funktion, des Subsystems oder sogar des Gesamtsystems in beliebiger geeigneter Form erfolgen. Beispielsweise kann eine derartige Wartung mittels Rekalibrierungskomponenten, Zurücksetzungskomponenten, Reinitialisierungkomponenten und -software, Reinstallierungssoftware, Ersatzkomponenten, einschließlich individueller Komponenten und vor Ort austauschbarer Einheiten, und so fort erfolgen. Die Sortierung der Empfehlungen nach Vorrang kann sich nach statistischen Wahrscheinlichkeiten richten, wie sie durch ein Bayesianisches Netzwerk definiert sind, und können ferner Faktoren berücksichtigen, wie sie oben erörtert wurden, z.B. Ausfallzeit, Kosten von Austauschelementen, Kosten von Wartungsaufrufen durch Wartungstechniker und Wartungspersonal, Transport- und Lagerkosten und so fort.
  • Das in 4 schematisch veranschaulichte System ermöglicht anschließend eine intelligente Entscheidung hinsichtlich des Wartungskonzepts, das mit Blick auf die Auswahl der geeigneten Wartungsempfehlung in Betracht gezogen werden sollte. Da viele derartige Konzepte in Frage kommen können, und für ein komplexes Maschinensystem sofort oder im Laufe der Zeit durchgeführt werden können, besteht insbesondere eine vordringliche Aufgabe darin, zu ermitteln, welches der Konzepte das aufgetretene oder potentiell erwartete servicebedürftige Ereignis am effizientesten ansprechen könnte. Das Indikatoranalysemodul 60 empfängt daher Daten von dem komplexen System 12 entweder automatisch oder durch Abruf der Daten von den einzelnen Komponenten oder von dem Memorymodul 18. In diesem Stadium können die Daten als Indikatoreingabedaten betrachtet werden, die in 4 allgemein mit dem Bezugszeichen 88 bezeichnet sind. Wie oben erwähnt, können gewisse Daten erfasst werden, während andere Daten manuell oder durch ein halbautomatisches System eingegeben werden können. Da sich nicht sämtliche Indikatoren genau erfassen lassen, können gewisse Indikatoren insbesondere Beurteilungen, visuelle Untersuchungen, akustische Untersuchungen, durch einen Benutzer initiierte Detektions- oder Analyseroutinen, und so fort erfordern. In ähnlicher Weise können die Indikatoreingabedaten von einer Wartungsworkstation 48 oder einem ähnlichen Eingabegerät entgegengenommen werden. Auf diese Weise können Wartungstechniker, Operator, Benutzer oder anderes Personal einfach Rohdaten zur Verfügung stellen, aus einem Menü Optionen auswählen, Beschreibungen bereitstellen, und so fort hinsichtlich Ereignissen wie Auffälligkeiten von Komponenten, Gerüchen, Abgasen oder einer beliebigen ungewöhnlichen Bedingung, die als ein Hinweis auf einen Fehler oder ein servicebedürftiges Ereignis zu erachten ist.
  • Das Indikatoranalysemodul 60 stellt diese Daten zusammen und übermittelt sie an ein Konzeptwahlmodul 62. Das Konzeptwahlmodul 62 holt Daten von einem allgemein mit Bezugszeichen 30 bezeichneten Arbeitsspeicher und speichert die Daten darin. Das Konzeptwahlmodul 62 kann auf ein oder mehrere mit Bezugszeichen 64 bezeichnete Konzepte zugreifen, die wieder einer oder mehreren Komponenten, Funktionen, Subsystemen oder vor Ort austauschbaren Einheiten entsprechen, die die Ausgangsursache eines servicebedürftigen Ereignisses sein könnten. Das Konzeptwahlmodul 62 wählt ein oder mehrere dieser Konzepte als Grundlage für ein Zusammenstellen von Wartungsempfehlungen. In der in 4 veranschaulichten Ausführungsform werden flexible Kriterien 90 ermittelt und für eine Verwendung durch das Konzeptwahlmodul 62 gespeichert. Ein Vorteil der flexiblen Kriterien 90 ergibt sich aus der Befähigung, vielfältige Konzepte implementieren zu können, die im Laufe der Zeit wie nachstehend beschrieben selbst verfeinert werden können und zwischen und unter den Konzepten basierend auf Kriterien auszuwählen können, die selbst mit der Zeit weiter entwickelt und verfeinert werden.
  • Die flexiblen Konzeptwahlkriterien 90 können mittels eines beliebigen geeigneten Rechnerprogrammkodes implementiert werden. Im Allgemeinen können einfache oder in hohem Maße komplexe Kriterien verwendet werden. In einem vorliegende Ausführungsbeispiel werden beispielsweise einzelne Indikatoren, die identifizierbare und eingegrenzte Ausgangsursachen für servicebedürftige Ereignisse repräsentieren, mit den durch das Indikatoranalysemodul 60 gesammelten Indikatoreingabedaten verglichen. Der Eingabedatensatz wird anschließend überprüft und mit den Indikatoren verglichen, die den vielfältigen Wartungskonzepten 64 zugeordnet sind. Zwischen den Eingabedatensatz und den Indikatoren werden Korrelationen ermittelt, indem beispielsweise die Reihe der in dem Eingabedatensatz vorhandenen Indikatoren (nach Zustand, Wert, Bereich, und so fort) einfach abgeglichen werden. Das eine oder die mehreren Konzepte werden anschließend auf der Basis solcher Abgleiche aus dem verfügbaren Satz von Konzepten gewählt. Alternative Techniken zum Bestimmen der flexiblen Kriterien 90 können beinhalten: Gewichten gewisser Indikatoren, z.B. eine genauere Lokalisierung zu ermöglichen, Minimierung von Kosten, die speziellen Indikatoren zugeordnet sind, Minimierung von Kosten, die der Art der sich aus der Konzeptwahl ergebenden oberflächlichen Empfehlung zuzuordnen sind, Minimierung von Kosten, die im Zusammenhang mit einem Austausch von speziellen Komponenten oder Funktionen entstehen, Zeitbedarf der Wartung und so fort. Andere flexible Kriterien können Kriterien einschließen, die auf Auswahlsystemen, die auf Annahmen begründet sind, und auf komplexeren Auswahlalgorithmen basieren. Die flexiblen Kriterien 90 werden vorzugsweise mittels eines austauschbaren Rechnerprogrammkodes oder Codesegmenten definiert, um mit den wachsenden Erfahrungen über das System oder dem Erkennen von Tendenzen eines Wartungsbedarfs ein Anpassen oder Ersetzen der Kriterien zu ermöglichen.
  • Basierend auf den Kriterien 90 arbeitet das Konzeptwahlmodul 62 vorzugsweise in einer vollautomatisierten Weise, um unter den verfügbaren Wartungskonzepten 64 ein Wahl zu treffen, um eine Wartungsstrategie zu implementieren. Der Fachmann wird zu schätzen wissen, dass die Verwendung eines automatisierten Konzeptwahlmoduls 62, der auf flexiblen Kriterien 90 basierend arbeitet, mit einem Anwachsen der Anzahl von Konzepten und der Komplexität des Systems die Identifizierung möglicher Ausgangsursachen servicebedürftiger Ereignisse im Vergleich zu manuell oder halbautomatischen Systemen erheblich verbessert. Nach einer Wahl des einen oder der mehreren Konzepte durch den Konzeptwahlmodul 62, führt ein Konzeptanwendungsmodul 92 das Konzept durch, um ein oder mehrere Wartungsempfehlungen zu erzeugen. Die Wartungsempfehlungen können eine beliebige oder sämtliche der vielfältigen Arten von Empfehlungen, wie sie oben beschriebenen sind, beinhalten, die in einer nach Vorrang sortierten Liste zum Ansprechen des servicebedürftigen Ereignisses aufgeführt sein können. Das Modul 92 erzeugt anschließend Empfehlungen oder einen Bericht 94, der im Allgemeinen in der Form des gemäß 9 weiter unten erörterten Gültigkeitsprüfungsberichts 86 erstellt sein kann. Die Empfehlungen und der Bericht können lokal an einem Ort, an dem das Konzeptanwendungsmodul betrieben wird, ausgegeben werden oder können über eine Netzwerkverbindung an einen Wartungstechniker oder an einen Ort übermittelt werden, an dem eine Wartung oder Wartungsabfertigung ausgeführt werden kann. Darüber hinaus sollte es klar sein, dass für den "Bericht" eine beliebige Form vorgesehen sein kann, einschließlich einer durch ein beliebiges geeignetes Mittel durchgeführte Benachrichtigung über die Ergebnisse der Konzeptanalyse, z.B. die Erfordernis von Wartungsmaßnahmen, Wartungsaufrufe, Austausch von Teilen, Bestellung von Teilen, Teileversand, Wartungsplanung, und so fort. Dementsprechend kann sich eine solche Benachrichtigung an Clients, Wartungspersonal, Dienstleister, Anbieter, und so fort richten. Zu den Mitteln für derartige Berichte und Benachrichtigungen können herkömmliche telefonische oder schriftliche Mitteilungen, elektronische Nachrichten, PDA-Mitteilungen, und dergleichen zählen.
  • Wie oben erwähnt, schaffen die vorliegenden Techniken außerdem eine Verfeinerung und Bewertung der Leistung der vielfältigen entwickelten und implementierten Konzepte. 5 zeigt einen Überblick über vielfältige Funktionalitäten des oben mit Bezug auf 2 erörterten Konzeptanalyse/Bewertungsmoduls. Das Modul 50 ermöglicht eine Identifizierung der Genauigkeit oder Leistung der vielfältigen Konzepte und der durch das Wartungssystem vorgeschlagenen Empfehlungen. Im Allgemeinen wird die Analyse auf der Basis von Empfehlungen des Konzepts durchgeführt, wie es durch das oben mit Bezug auf 4 zusammenfassend erörterte System ermittelt wurde. Die Empfehlungen der einzelnen Konzepte werden einem Analysekonzept 96 zur Verfügung gestellt, bei dem auf der Basis zusätzlicher Daten, die die Genauigkeit oder Zuverlässigkeit des Konzepts in der implementierten Form kennzeichnen könnten, Vergleiche durchgeführt werden. In einer vorliegenden Implementierung könnten derartige zusätzliche Eingaben beispielsweise aus Ereignis- oder Konfigurationslogbüchern 98 stammen, die in einzelnen Systemkomponenten, Subsystemen, vor Ort austauschbaren Einheiten oder vielfältigen Systemarbeitsspeichervorrichtungen, beispielsweise dem in 1 veranschaulichten Memorymodul 18 gespeichert sind. In komplexen Systemen können viele derartige Ereignis- oder Konfigurationslogbücher verfügbar sein, auf die zugegriffen werden kann, um zu identifizieren, ob nachfolgende Ereignisse durchgedrungen sind, ob Konfigurationen anschließend verändert wurden, ob während eines Wartungsaufrufs Konfigurationen auf der Grundlage der Empfehlungen verändert wurden, und so fort. Alternativ oder zusätzlich zu dem Ereignis- oder Konfigurationslogbuch 98 können von Feldingenieuren oder Wartungtechnikern ausgehende mit Bezugszeichen 100 bezeichnete Rückmeldungen entgegengenommen werden. Solche Rückmeldungen können beispielsweise Daten hinsichtlich ausgeführter Tests, veränderter Konfigurationen, ausgetauschter Elemente, und so fort beinhalten. Zuletzt können mit Bezugszeichen 102 bezeichnete nachfolgende Logbücher abgefragt werden, die identisch mit den Ereignis- und Konfigurationslogbüchern 98 sind oder diesen ähneln. Solche nachfolgenden Logbücher können Daten bereitstellen, die zusätzlich entstandenen Wartungsbedarf, zusätzlich unternommene Konfigurationsänderungen und so fort kennzeichnen.
  • Das Analysemodul 96 vergleicht diese Eingabedaten und ermittelt, ob die Konzepte zugrundeliegende Ursachen von servicebedürftigen Ereignissen genau abbilden. Wie weiter unten anhand von 10 und 11 eingehender erörtert, sind nicht sämtliche Empfehlungen erforderlich oder sogar angemessen für ein Ansprechen eines zugrundeliegenden servicebedürftigen Er eignisses. In Fällen, in denen beispielsweise ein Fehler auftritt, der auf eine andere als die durch das Konzept vorausgesagte Ausgangsursache zurückzuführen ist, kann eine derartige Information durch das Analysemodul 96 identifiziert werden, z.B. durch eine Analyse anderer oder zusätzlicher Wartungsaufgaben, die durch Wartungspersonal ausgeführt werden, um das servicebedürftige Ereignis zu beheben. Auf der Grundlage einer durch das Modul 96 ausgeführten Analyse, kann ein Bericht oder Datenblatt 104 zusammengestellt werden. Auch hier, die Arten der Berichte, die durch das weiter unten gemäß 10 und 11 eingehender erörterten Analysemodul erzeugt werden. Im Allgemeinen können die durch das Datenblatt 104 wiedergegebenen Ausgabedaten oder Berichte jedoch Empfehlungen für Veränderungen der Konzepte, Rückmeldungstatistiken, Wahrscheinlichkeitsvoraussagen, dass Indikatoren oder Kombinationen von Indikatoren auf gewisse Elemente, Komponenten, Funktionen, Subsysteme, vor Ort austauschbare Einheiten oder dgl. zurückzuführen sind, und so fort enthalten. Solche Anzeigen können in beliebiger Form vorgesehen sein, beispielsweise dargestellt durch die einfache Auflistung 106 in 5.
  • Um die Schleife des gesamten Zyklus der Wartungskonzeptentwicklung zu schließen, können anschließend mittels des Entwicklungs-/Analyse-Systems 26 Änderungen an den Konzepten vorgenommen werden. In einem allgemeinen Sinn können solche Änderungen eine Abänderung der Konzepte selbst beinhalten, beispielsweise, indem ein oder mehrere Fehlermodi und ein oder mehrere Indikatoren einbezogen oder ausgeschlossen werden. Andere Veränderungen der Konzepte können eine Änderung der Wahrscheinlichkeiten eines Auftretens gewisser Ereignisse oder Indikatoren, Änderungen der Kostenstrukturen, und so fort enthalten. Ferner ist zu beachten, dass in diesem Stadium gewisse Veränderungen auch an den flexiblen Kriterien erfolgen können, die, wie oben anhand von 4 erörtert, für eine Wahl des Konzepts verwendet werden. Derartige vorzunehmende Veränderungen können mittels automatisierter, halbautomatischer oder manueller Verfahren erfolgen.
  • Wie oben beschrieben, wird durch die vorliegenden Techniken ermöglicht, sowohl zeitgleich mit der Konstruktion eines Systems als auch nachfolgend eine Wartbarkeit eines komplexen Systems zu entwerfen.
  • 6 veranschaulicht ein exemplarisches Interface zum Definieren eines Wartungskonzepts gemäß Aspekten der vorliegenden Technik, wie es durch das oben beschriebene System implementiert sein kann. In 6 ist ein erweitertes FMEA-Interface 68 dargestellt. Das Interface kann durch eine beliebige geeignete Rechnerprogrammroutine definiert sein, beispielsweise in Form eines herkömmlichen Spreadsheets. Das Interfaceübersetzungsmodul 72 und das Konzeptdefinitionsmodul 74 (siehe 3) ermöglichen eine Schnittstellenverbindung der durch das Interface definierten Daten mit einer Modellierungssoftware, die dazu dient, das Konzept auf der Grundlage der Daten zusammenzustellen. In der in 6 veranschaulichten Ausführungsform sind Felder vorgesehen, um die Komponente oder Funktion zu definieren, der das Konzept in dem System entspricht. In dem veranschaulichten Beispiel ermöglicht ein Modalitätsfeld 110 ein Definieren einer beispielsweise die medizinischen Diagnostik betreffenden Systemmodalität. Ein Feld 112 ermöglicht eine Identifikation des Systemkonzepts, während Felder 114 und 116 eine speziellere Identifikation eines Subsystems und einer Komponente oder Funktion ermöglichen. Es können sonstige oder unterschiedliches Systeme, Subsysteme, Komponenten, Funktionen, vor Ort austauschbare Einheiten und ähnliche Identifikationsfelder vorgesehen sein.
  • Das Interface sieht ferner mehrere Gruppen von Feldern vor, um maßgebende Daten zu spezifizieren, die zum Definieren des einzelnen Konzepts verwendet werden. In dem veranschaulicht Ausführungsbeispiel werden Daten beispielsweise durch ein Element 118, einen Fehlermodus 120, Wartungsmaßnahmen 122 und Indikatoren 124 vorgesehen. Die Elemente stellen einen von der Ebene der Komponenten ausgehenden Zusammenbruch einzelner Aspekte, Ausstattungsmerkmale, oder Unterkomponenten bereit, der die Ausgangsursache eines servicebedürftigen Ereignisse sein kann. Für jedes derartige Element können eine Reihe von Fehlermodi definiert sein. Für derartige Fehlermodi können Wartungsmaßnahmen definiert sein, die den individuellen Fehlermodus ansprechen. Die speziellen Elemente, die möglicherweise der Anlass für die servicebedürftigen Ereignisse sein können, und die individuellen Fehlermodi können dann durch einen oder mehrere Indikatoren charakterisiert werden. Auch hier werden die Indikatoren im Allgemeinen Daten entsprechen, die aus einem System erfasst oder gesammelt sein können oder manuell oder in einer halbautomatischen Weise eingegeben sein können.
  • Indem wieder auf die Elementdaten in dem in 6 veranschaulichten Ausführungsbeispiel eingegangen wird, enthalten die Elementdaten 118 ein Kennzeichen für ein spezielles Element, Merkmal oder eine Unterkomponente, sowie einen dem Element zugeordneten Wahrscheinlichkeitswert. Die anfänglich durch das System oder durch einen Wartungskonzeptkonstrukteur zugewiesene Wahrscheinlichkeit repräsentiert die Wahrscheinlichkeit, mit der das spezielle Element einem servicebedürftigen Ereignis für die Komponente zugeordnet werden kann, für die das Wartungskonzept zu definieren ist. Wie weiter unten erwähnt, können derartige Wahrscheinlichkeiten einer Veränderung unterworfen werden, und können gemäß Aspekten der vorliegenden Technik im Laufe der Zeit auf der Grundlage der oben beschriebenen Rückmeldung und Analyse verbessert werden. Es können also anfängliche Wahrscheinlichkeitsdaten auf der Basis von in demselben oder ähnlichen Systemen im Laufe der Zeit und aufgrund deren Wartung gewonnenen Erfahrungen verfeinert werden.
  • Die in dem Interface bereitgestellten Fehlermodusdaten 120 enthalten in ähnlicher Weise eine Identifikation 130 jedes Fehlermodus und können eine mit Bezugszeichen 132 bezeichnete Anzeige über die Ernsthaftigkeit oder das Ausmaß der Gefahr des Fehlermodus enthalten. Die Information über die Ernsthaftigkeit können die Wahl eines speziellen Konzepts bei einer Ermittlung von Wartungserfordernissen beeinflussen und können in anderen Zusammenhängen eingesetzt werden, z.B. um empfohlene Wartungsstrategien für ein Eingehen auf die speziellen Fehlermodi zu definieren. Darüber hinaus können schwerwiegende Fehlermodi den Konstrukteur veranlassen, zusätzliche Sensoren oder Indikatoren vorzusehen, um einen hohen Grad an Zuverlässigkeit bei der Erfassung und Lokalisierung derartiger Fehlermodi zu erzielen. Die Ernsthaftigkeitsfaktoren können in Verbindung mit Wahrscheinlichkeiten des speziellen Fehlermodus, der einem Problem in Zusammenhang mit einem speziellen Element zugrunde liegt, mit Bezugszeichen 134 bezeichnet, als Grundlage zur Berücksichtigung der Austauschbarkeit einzelner Komponenten dienen, wie im Falle von vor Ort austauschbaren Einheiten, und so fort. Die hinsichtlich der vielfältigen Fehlermodi identifizierten Wahrscheinlichkeiten können, wie im Falle der Wahrscheinlichkeiten 128, zu Beginn durch den Systemkonstrukteur eingegeben werden. Diese Wahrscheinlichkeiten können selbstverständlich im Laufe der Zeit in dem Maße verfeinert werden, wie zusätzliche Daten gewonnen werden oder die Erfahrung wächst. Ferner ist zu beachten, dass die Wahrscheinlichkeiten 134 den individuellen Fehlermodi entsprechen, wobei für jedes identifizierte Element mehrere Fehlermodi möglich sind.
  • Die Wartungsmaßnahmedaten 122 ermöglichen ein Definieren einzelner Maßnahmen, die herangezogen werden können, um servicebedürftige Ereignisse, und insbesondere die Fehlermodi anzusprechen. Wie oben erwähnt, können Wartungsmaßnahmen, um nur einige zu nennen, eine Kalibrierung, ein Zurücksetzen von Systemen und der Software, ein Neuladen von Software, ein Austausch von Komponenten etc. beinhalten. Zusätzlich zu der Identifikation der Wartungsmaßnahme 136 können mit Bezugszeichen 138 bezeichnete im Zusammenhang mit den Maßnahmen auftretende Kosten geschätzt werden. Solche Kosten können als Grundlage verwendet werden, um gewisse Empfehlungen zu bewerten, um zu definieren, in welchen Fällen Komponenten in vor Ort austauschbaren Einheiten zugeordnet werden sollten, um Wartungskosten nachzuvollziehen, um eine Grundlage für ein Festlegen von Wartungsvertragsgebühren zu erhalten, und so fort.
  • Zuletzt stellen die Indikatordaten 124 eine Reihe von Spezifikationen für die einzelnen Datenwerte bereit, die dazu verwendet werden, um das interessierende spezielle Konzept hinsichtlich eines Ansprechens auf ein servicebedürftiges Ereignisses auszuwählen. Die Daten bilden ferner eine Grundlage um potentielle Ausfälle zu erkennen und zu lokalisieren, und Wartungsmaßnahmen nach Vorrang zu sortieren. Darüber hinaus stellen die Indikatoren dem Konstrukteur, wie nachstehend be schrieben, eine brauchbare Grundlage zur Verfügung, um einzuschätzen, ob sich gewisse Fehlermodi erfassen lassen, und sofern ein Erfassen möglich ist, abzuschätzen inwieweit eine Eingrenzung und Lokalisierung einzelner Elemente in Fehlermodi unterstützt wird. In dem veranschaulichten Ausführungsbeispiel, beinhalten die Indikatordaten 124 eine Meldungsidentifikation 140, sofern eine Meldung vorhanden ist, und eine Quelle 142, aus der die Meldungs-ID zu entnehmen ist. In vielen komplexen Systemen können beispielsweise Logbuchdaten aus Komponenten und Systemen entnommen werden, die die Grundlage für spezifische Identifikationen von Ausfällen oder Ereignissen vorsehen. Allerdings werden nicht sämtliche Elemente oder Fehlermodi derartigen Logbüchern entsprechen und gewisse Indikatoren sind nicht durch derartige Logbücher verfügbar. Ein Namensfeld 144 ermöglicht ein Identifizieren des speziellen Indikators. Wie oben erwähnt, können einige Arten von Indikatoren vorgesehen sein, beispielsweise in 6 mit "Laufzeit"-Indikatoren bezeichnete Indikatoren, die während eines normalen Betriebs des Systems verfügbar sind, sowie Indikatoren, die durch einen Benutzer initiierte Sequenzen erfordern, und Indikatoren die einen manuellen Eingriff oder eine manuelle Eingabe verlangen. Für die zuletzt erwähnten beiden Arten von Indikatoren kann eine mit Bezugszeichen 146 bezeichnete Erfassungszeit identifiziert werden, und der spezielle Indikatortyp kann bei Bezugszeichen 148 identifiziert werden. Diese Daten können darüber hinaus in einer Entwurfsphase verwendet werden, um Punkte in dem Verfahren oder System zu identifizieren, an denen Fühler oder Sensoren positioniert werden können, um den Wartungsrhythmuszeitraum und die Eingrenzung individueller Fehlermodi und Elemente auf der Grundlage des Indikatortyps zu verbessern.
  • Wie oben erwähnt, können zusätzliche Interfaces vorgesehen sein, um die Wartungskonzepte gemäß Aspekten der vorliegenden Technik zu definieren. 7 veranschaulicht ein weiteres Interface dieser Bauart. In dem Interface 70 sind Daten enthalten, die jenen ähneln, die in dem Interface 68 nach 6 vorgesehen sind, jedoch in einem unterschiedlichen Format, an das das Wartungspersonal möglicherweise bereits gewohnt ist. Es können daher Daten bereitgestellt werden, die eine Identifikation einer Modalität, eines Systems, eines Subsystems, einer Komponente und so fort ermöglichen, wie sie bei Bezugszeichen 110, 112, 114 bzw. 116 dargestellt sind. Darüber hinaus werden Fehlermodusidentifikationsdaten 120 gemeinsam mit Wartungsmaßnahmedaten 122 bereitgestellt. In ähnlicher Weise werden Datenelementidentifikationsdaten 118 bereitgestellt. Wie im Falle des Interface 68 nach 6, enthalten die Elementdaten sowohl Elementidentifikationsdaten 126, als auch Wahrscheinlichkeitsabschätzungen 128. In ähnlicher Weise enthalten die Fehlermodusdaten 120 Fehlermodusidentifikationsdaten 130, eine Ernsthaftigkeitsklassifizierung 132 und eine Wahrscheinlichkeitsabschätzung 134. Darüber hinaus ist eine Identifikation spezieller Indikatoren für spezielle Ursachen servicebedürftiger Ereignisse vorgesehen und mit den einzelnen Wartungsmaßnahmen, Fehlermodi und Elementen korreliert. In dem in 7 gezeigten Ausführungsbeispiel ist ein mit Bezugszeichen 150 bezeichnetes abgerundetes Produkt der Wahrscheinlichkeitsabschätzungen 128 und 134 vorgesehen.
  • In der Ansicht des Interface 70 nach 7 ist die Interdependenz zwischen den einzelnen Indikatoren und den Fehlermodi, Wartungsmaßnahmen und Elementen deutlicher zu erkennen. Insbesondere weist das in 7 veranschaulichte Beispiel sieben gesonderte Indikatoren und neun potentielle Feh lermodi auf. Es lässt sich beispielsweise feststellen, dass ein Indikator 3 sowohl einem Fehlermodus 3 als auch einem Fehlermodus 9 zugeordnet ist, wobei diese Korrelationen beispielsweise in den in 7 mit dem Bezugszeichen 152 bezeichneten Blöcken zusammengefasst sind. Die Wahl von Indikatoren kann daher während der Systemkonstruktion geschickt eingerichtet werden, so dass individuelle Fehlermodi eindeutig mit speziellen Indikatoren korreliert werden können, und in Fällen, in denen sich Fehlermodi nicht eindeutig unterscheiden oder eingrenzen lassen, können zusätzliche Indikatoren erstellt werden. Darüber hinaus können in Fällen, in denen Kostenschätzungen zeigen, dass sich Wartungsmaßnahmen ökonomisch kombinieren lassen, Indikatoren in ähnlicher Weise kombiniert oder auch eliminiert werden. Das System ermöglicht dementsprechend sowohl das Hinzufügen von Indikatoren (beispielsweise durch das Hinzufügen von Sensoren) sowie das potentielle Verringern der Zahl von Indikatoren (beispielsweise, indem die Anzahl erforderlicher Sensoren reduziert wird). In ähnlicher Weise ermöglicht das System dem Konstrukteur eine Rückmeldung für Systemkonstrukteure vorzusehen, um in kombinierte vor Ort austauschbare Einheiten Komponenten oder Funktionen einzubeziehen, die sich im Falle spezieller Fehlermodi oder Elemente wirtschaftlich austauschen lassen.
  • Wie oben erwähnt, wird auf der Grundlage der durch die Interfaces 68 und 70 nach 6 und 7 vorgesehenen Konzeptdefinition, und des Konzeptdefinitionsmoduls und der Software, wie sie oben gemäß 3 beschrieben sind, ein Konzept entwickelt, und kann bewertet werden. In einem vorliegenden Ausführungsbeispiel wird ein Analysedatenblatt 84 entwickelt, wie es in 8 veranschaulicht ist. In dem veranschaulichten Ausführungsbeispiel sieht das Datenblatt für das spezielle Kon zept mit Bezugszeichen 110, 112, 114 und 116 bezeichnete Identifikationsdaten vor, die den von dem Konstrukteur eingegeben Daten entsprechen. Eine allgemeine Übersicht 154 der Konzeptanalyse und Ausgabe ist ebenfalls vorgesehen. In dem veranschaulichten Beispiel, das dem durch die Interfaces 68 und 70 nach 6 bzw. 7 gebildeten Konzept entspricht, werden zwei einzelne Elemente analysiert (siehe Daten 126 in 6 und 7), wobei neun gesonderte Fehlermodi (siehe Daten 130 in 6 und 7) auf sieben gesonderten Indikatoren (siehe Daten 144 in 6 und 7) basieren. Diese in 8 mit Bezugszeichen 160, 162 und 164 bezeichneten Elemente werden zusammengefasst. Darüber hinaus wird eine Identifikation der von dem Konzept verwendeten Art von Indikatoren zusammengefasst.
  • Das Datenblatt fasst ferner die Erfassbarkeit der vielfältigen Elemente und Fehlermodi zusammen. Die bei Bezugszeichen 156 in 8 zusammengefasste Erfassbarkeit enthält eine Übersicht der Anzahl verwendeter Elemente und den mit Bezugszeichen 166 bezeichneten Prozentsatz jener Elemente, für die ein Versagen erfassbar ist, sowie eine tabellarische Aufstellung der Anzahl von Fehlermodi im Zusammenhang mit deren prozentualer Erfassbarkeit, wie sie bei Bezugszeichen 168 zusammengefasst ist. In dem in 8 veranschaulichten Ausführungsbeispiel, ist ferner eine mit Bezugszeichen 170 bezeichnete gewisse Darstellung der Arten von Indikatoren vorgesehen, die verwendet werden, um das Versagen von Elementen sowie Fehlermodi in dem Konzept zu erfassen.
  • In dem veranschaulichten Ausführungsbeispiel, fasst das Datenblatt ferner zusammen, bis zu welchem Grad die Eingrenzung des Versagens der Elemente und das Auftreten der Fehlermodi gemäß dem Konzept erfasst werden können. Die in 8 bei Bezugszeichen 158 dargestellte Übersicht der Eingrenzung, enthält in dem veranschaulichten Ausführungsbeispiel eine mit Bezugszeichen 172 bezeichnete Übersicht über die verwendeten speziellen Elemente, über deren vielfältige Fehlermodi und über die Arten von Indikatoren die für deren Eingrenzung erforderlich sind. Die Elemente und Fehlermodi in der Übersicht 172 ermöglichen ein genaues Eingrenzen eines Fehlers. Darüber hinaus sind mit Bezugszeichen 176 bezeichnete Überblicke über jene einzelne Elemente und deren Fehlermodi, die sich nicht eindeutig eingrenzen lassen, in Verbindung mit mit Bezugszeichen 178 bezeichneten Daten der Wahrscheinlichkeit eines Auftretens, der Ernsthaftigkeit, der Kosten und der über das Konzeptentwurfsinterface eingegebenen Wartungsmaßnahmen vorgesehen.
  • Es sollte beachtet werden, dass die aufgrund der vorliegenden Techniken verfügbare Analyse und Bewertung fachkundige Entscheidungen hinsichtlich Empfehlungen von Wartungsmaßnahmen, sowie der Konstruktion des Systems selbst ermöglichen. Wie sich beispielsweise dem Beispiel nach 8 entnehmen lässt, werden beide Fehlermodi 7 und 8 (FM7 und FM8) durch eine Wartungsmaßnahme 7 angesprochen, z.B. den Austausch einer Komponente einer vor Ort austauschbaren Einheit. In diesem Fall kann der Systemkonstrukteur erkennen, das kein Bedarf für ein Eingrenzen der Fehlermodi 7 und 8 besteht (da die Antwort auf beide Fälle dieselbe ist). Indikatoren und zugeordnete Sensoren für ein derartiges Eingrenzen könnten in diesem Fall zumindest hinsichtlich eines Wartungsbedarfs ausgeschlossen werden (selbstverständlich könnten von derartigen Sensoren gelieferte Daten aus anderen Gründen in dem System von Nutzen sein). Während Fehlermodi 3 und 9 eingegrenzt sind und unterschiedliche Wartungsmaßnahmen beinhalten, kann in ähnlicher Weise mit Blick auf die geringen Kosten solcher Antworten (siehe Spalte ICV in dem Interface nach 8) eine Empfehlung erfolgen, in beiden Fällen mit beiden Wartungsmaßnahmen zu antworten (beispielsweise Versenden beider Teile um sie auszutauschen). In solchen Fällen kann in Anbetracht der geringen Kosten des Teils im Vergleich zu den potentiellen Kosten eines Bereitstellens eines Indikators und zugeordneter Sensoren, um die Fehlermodi voneinander abzugrenzen, ein Bereitstellen eines möglicherweise unbenötigten Teils gerechtfertigt sein. Falls andererseits die Kosten höher und die Kostendifferenzen größer sind, kann der Einsatz des zusätzlichen Indikators und Sensors gerechtfertigt sein.
  • Das Analysedatenblatt kann eingesetzt werden, um in Verbindung mit anderen Berichten und Ausgabedokumenten zu analysieren, ob das Konzept einzelne Ausgangsursachen servicebedürftiger Ereignisse ausreichend charakterisiert und eingrenzt. Ein zweites Ausgabeformat ist in 9 in Form eines Diagnoseberichts dargestellt. Der Gültigkeitsprüfungsbericht 86 identifiziert einen speziellen Abfertigungs- oder Wartungsauftrag 180. Auf der Grundlage der für das spezielle Wartungskonzept evaluierten Indikatoren und der Entsprechung dieser Indikatoren gegenüber dem einzelnen Element und identifizierten Fehlermodi wird eine in 9 mit Bezugszeichen 182 bezeichnete wahrscheinliche Ursache eines servicebedürftigen Ereignisses identifiziert. Wie oben erwähnt, werden derartigen Ursachen anschließend Wartungsmaßnahmen zugeordnet, deren Empfehlung bei Bezugszeichen 184 vorgesehen ist. Falls gewünscht, kann eine Liste möglicher Wartungsmaßnahmen dieser Art mit entsprechenden Ursachen versehen sein. Die Liste kann ferner basierend auf Faktoren wie Wahrscheinlichkeit, frühere Erfah rung, Kosten, Wartungszykluszeit, und so fort, nach Vorrang sortiert sein.
  • Die Darstellung beinhaltet eine Identifikation des speziellen für die Analyse verwendeten Konzepts, die Identifikationsbezeichnungen entspricht, die in der Konstruktion des Konzepts festgelegt wurden. In dem veranschaulichten Ausführungsbeispiel gehören zu diesen Identifikationen mit Bezugszeichen 110, 112, 114 und 116 bezeichnete Identifikationen einer Modalität, eines Systems, eines Subsystems und einer Komponente. Es könnten selbstverständlich andere Arten einer Konzept- oder Systemkomponentenidentifikation verwendet werden. Da gewöhnlich vielfältigen Zustände aufweisende unterschiedliche Indikatoren vorliegen werden, werden die Zustände dieser Indikatoren ferner, wie bei Bezugszeichen 186 veranschaulicht, durch eine Auflistung der Indikatoren angegeben. Wie oben erwähnt, können in einem vorliegenden Ausführungsbeispiel derartige Indikatoren als "Laufzeit"-Indikatoren, deren Daten sich während eines normalen Betriebs des Systems sammeln lassen, sowie als durch einen Benutzer initiierte Indikatoren und als manuelle Indikatoren designiert sein. In dem veranschaulichten Ausführungsbeispiel erscheint ein einziger Indikator 1001 im Zustand Ein, während sämtliche andere Indikatoren entweder den Zustand Aus oder negativ aufweisen.
  • Der Gültigkeitsprüfungsbericht 86 kann während der Anfangsphase der Konstruktion des Wartungssystems verwendet werden, um beispielsweise die Leistung vielfältiger Wartungskonzepte zu untersuchen oder zu analysieren. Darüber hinaus können solche oder ähnliche Berichte aufgrund des Erfassens von servicebedürftigen Ereignissen erzeugt werden. Solche Ereignisse können während der Lebensdauer des Systems auftreten, und die Analyse kann in vielfältiger Weise ausgelöst werden, z.B. automatisch, durch Benutzereingriff, auf periodischer Grundlage, und so fort. Im Allgemeinen werden derartige diagnostische Berichte erzeugt, um nach dem Erfassen spezieller Indikatoren, der Wahl eines oder mehrerer Wartungskonzepte, der Anwendung des Wartungskonzepts auf die Indikatoreingabedaten und einer mittels der oben beschriebenen Verfahren nachfolgend erstellten Analyse Empfehlungen übersichtlich darzustellen.
  • Wie oben erwähnt, ermöglichen die vorliegenden Techniken außerdem im Laufe der Zeit eine Verbesserung der Wartungskonzepte und des gesamten Wartungssystems. Während durch die tatsächliche Wartung des Systems zusätzliche Erfahrung gewonnen wird, werden diese Daten insbesondere für den Einsatz in der Analyse der Genauigkeit und Effizienz der bestehenden Konzepte und für ein Verändern der bestehenden Konzepte oder des Maschinensystems gesammelt, um die Wartbarkeit zu verbessern. 10 veranschaulicht ein exemplarisches Wartungsrückmeldungsdatenblatt, das sich mittels der vielfältigen oben gemäß 3 zusammengefassten Module erzeugen lässt. In dem veranschaulichten Ausführungsbeispiel enthält das Datenblatt 188 eine Identifikation des speziellen zu bewertenden Konzepts, beispielsweise in Form der oben erwähnten Felder 110, 112, 114 und 116. Da die Rückmeldung auf der Grundlage einer tatsächlich erfolgten Wartung vorgesehen ist, wird ein mit Bezugszeichen 190 bezeichneter Datumsbereich spezifiziert. Zusätzlich zu Fehlermodi, Entwurfsdaten, Wahrscheinlichkeiten, und so fort, werden, wie in 10 veranschaulicht, vielfältige in dem Konzept mögliche Wartungsmaßnahmen angezeigt. Diese Daten werden im Allgemeinen die Daten einschließen, die verwendet werden, um das Konzept wie oben beschrieben zu einzurichten.
  • Allerdings sind ferner zusätzlich tatsächliche Daten vorgesehen, die sich auf eine an einem System durchgeführte Wartung beziehen. Rückmeldungsdaten 194 sind vorgesehen, die vielfältige Felder einschließen. Wie beispielsweise mit dem Bezugszeichen 196 bezeichnet, wird die innerhalb des Datumsbereichs auftretende Anzahl von (Fehlermodi spezieller Elemente entsprechenden) Empfehlungen für eine spezielle Wartungsmaßnahme angezeigt. In dem veranschaulichten Ausführungsbeispiel wurden in dem Datumsbereich basierend auf der Wartungsmaßnahme 1 drei Empfehlungen vorgeschlagen. Ein Prozentsatz des tatsächlichen Auftretens ist bei Bezugszeichen 198 aufgelistet, wobei in dem veranschaulichten Ausführungsbeispiel sämtliche Ereignisse Wartungsmaßnahme 1 betrafen. Wie mit den Bezugszeichen 200 und 202 bezeichnet, enthält die Rückmeldung ferner eine Angabe hinsichtlich der Anzahl der korrekten Empfehlungen und der Anzahl der falschen Empfehlungen. Auf der Grundlage dieser Zählerstände wird eine mit dem Bezugszeichen 204 bezeichnete prozentuale Treffsicherheit des Konzepts angegeben. Im Allgemeinen stellt das Datenblatt eine Übersicht über Wartungsmaßnahmen zur Verfügung, die auf der Basis einer Anwendung des speziellen betrachteten Konzepts unternommen wurden. In Fällen, in denen die unternommenen Maßnahmen nach Maßgabe des Wartungspersonals einwandfrei den erforderlichen Maßnahmen entsprachen, erscheinen sämtliche Ereignisse als einwandfrei aufgeführt. Wenn allerdings Ereignisse als falsch angegeben sind, kann dies als ein Hinweis erachtet werden, das möglicherweise eine gewisse Änderung an dem Konzept vorzunehmen ist, beispielsweise andere Ausgangsursachen servicebedürftiger Ereignisse zu identifizieren sind, zwischen Ursachen derartiger Ereignisse zu unterscheiden ist, eine verbesserte Abgrenzung zwischen den Ausgangsursachen vorzusehen ist, und so fort.
  • Wo gewünscht können durch Detaildatenblätter der in 11 veranschaulichten Art detailliertere Daten vorgesehen sein. In dem allgemein mit dem Bezugszeichen 206 bezeichneten detaillierten Datenblatt sind, angedeutet durch Felder 110, 112, 114 und 116, ähnliche Systemkomponentenbezeichnungsdaten vorgesehen. In ähnlicher Weise wie in 10 veranschaulicht, ist auch ein mit dem Bezugszeichen 190 bezeichneter Datumsbereich für Wartungsaktivitäten angegeben. Allerdings stellt das detaillierte Datenblatt 206 Daten über die speziellen Wartungsempfehlungen zur Verfügung, die in dem Datumsbereich erfolgten. Aus dem veranschaulichten Ausführungsbeispiel lässt sich entnehmen, dass in dem Datumsbereich, wie durch die Zahl in der Spalte der Empfehlungen 196 in 10 angegeben, eine Wartungsmaßnahme 1 dreimal empfohlen wurde. In dem detaillierten Datenblatt nach 11 sind dieselben drei Ereignisse dann in Einträge 208 aufgegliedert. Die Einträge enthalten Einzelheiten, die Datum und Uhrzeit, die Vorgangsnummer, die Wartungsmaßnahme und den angesprochenen Fehlermodus betreffen. Zu den Daten gehören ferner mit Bezugszeichen 210 bezeichnete Einzelheiten, die kennzeichnen, ob die Wartungsmaßnahme korrekt oder nicht korrekt war. Darüber hinaus wird unter der mit Bezugszeichen 212 bezeichneten Rubrik die korrekte Maßnahme vermerkt. Solche Daten sind in hohem Maße nützlich, um zu bewerten, ob das Wartungskonzept den Fehlermodus korrekt identifiziert und den Fehlermodus der erforderlichen Wartungsmaßnahme korrekt zugeordnet hat. Auch hier kann die richtige Wartungsmaßnahme entweder durch menschliche Eingabe, z.B. durch einen Wartungstechniker, oder durch ein automatisches Erfassen von Änderungen, die sich in den Systemkonfigurationen aufgrund veränderter Ausrüstung ergeben, und so fort, identifiziert werden. In dem veranschaulichten Ausführungsbeispiel sieht das detaillierte Datenblatt ferner, wie unter dem Bezugszeichen 214 zusammengefasst, Aussagen über die im jeweiligen Fall vorliegenden speziellen Indikatoren und deren Zustand vor. Diese Daten können als Grundlage dienen, um einzuschätzen, ob ein zusätzlicher oder unterschiedlicher Fehlermodus und eine begleitende Wartungsmaßnahme spezifiziert werden kann, oder ob die vorhandenen Definitionen korrigiert oder verändert werden können. Die Rückmeldung kann auch eine Angabe zur Verfügung stellen, dass durch die bestehende Konzepte vorgesehene Erfassen oder Eingrenzen unzureichend ist, und dass ein oder mehrere zusätzliche Indikatoren oder Konzepte nützen würden, um die gewünschte Wartung zu erzielen. In ähnlicher Weise können die Daten eine Angabe darüber vorsehen, ob die durch das Konzept verwendeten Wahrscheinlichkeiten, die als Grundlage dienen, um zu ermitteln, welcher Fehlermodus mit höherer Wahrscheinlichkeit für einzelne Elemente zutrifft und für Komponenten angemessen ist. Im Laufe der Zeit stellen die Übersichts- und detaillierten Datenblätter ein außerordentlich nützliches Werkzeug dar, um Wartungskonzepte und eine Wahl derartiger Konzepte zu verbessern.
  • Eine Wartbarkeitsstrategie ist geschaffen, die das Definieren mehrerer Wartungskonzepte (64) für Komponenten (38), Funktionen (38), Subsysteme (36) und vor Ort austauschbare Einheiten (40) in einem komplexen Maschinensystem (12), sowie die Durchführung/Implementierung der Konzepte ermöglicht, um auf auftretende servicebedürftige Ereignisse und Fehlfunktionen hin Wartungen auszuführen und die Konzepte im Laufe der Zeit zu verbessern. Die Konzepte (64) können in einer geeigneten Weise zugeordnet sein, so dass sie ausgewählt werden können, um auf erfassbare und eingrenzbare Ausgangsursachen von servicebedürftigen Ereignissen bei deren Auftreten anzusprechen, und die angemessenen Konzepte werden bei einem Auftreten derartiger Ereignisse auf der Basis vordefinierter Indikatoren (164) ausgewählt. Wenn im Laufe der Zeit Wartungsereignisse auftreten und durch Empfehlungen (184) angesprochen werden, die durch jeweilige Konzepte vorgeschlagen sind, werden Daten erfasst, die als die Grundlage für ein Weiterentwickeln der Konzepte dienen, um Ausgangsursachen von servicebedürftigen Ereignissen und Fehlfunktionen angemessener anzusprechen, und die Wahl der Konzepte optimal anwendungsgemäß hinsichtlich eines Ansprechens von servicebedürftigen Ereignissen und Fehlfunktionen zu verbessern.
  • Während die Erfindung vielfältigen Abwandlungen und alternativen Ausprägungen zugänglich sein kann, sind hier spezielle Ausführungsbeispiele exemplarisch in den Figuren gezeigt und im Einzelnen erläutert. Es sollte allerdings klar sein, dass nicht beabsichtigt ist, die Erfindung auf die offenbarten Ausprägungen zu beschränken. Vielmehr soll die Erfindung sämtliche Abwandlungen, äquivalenten Formen und Möglichkeiten einschließen, die in den durch die nachfolgenden Ansprüche definierten Schutzbereich der Erfindung fallen.

Claims (10)

  1. Verfahren zum Definieren eines Wartungskonzepts für ein komplexes System, mit den Schritten: Erzeugen eines Wartungskonzepts (64) für eine Komponente (38), eine Funktion (38), ein Subsystem (36) oder eine vor Ort austauschbare Einheit (40) eines komplexen Systems (12), wobei das Wartungskonzept mehrere Fehlermodi (162) und Indikatoren (164) für die Fehlermodi aufweist; Anwenden des Wartungskonzepts (64) für die Empfehlung einer Wartungsmaßnahme (136, 184), die ein servicebedürftiges Ereignis auf der Grundlage der Indikatoren (164) und Eingabedaten (172) aus dem komplexen System anspricht; und Bewerten des Wartungskonzepts (188) auf der Grundlage der ausgeführten Wartungsmaßnahmen.
  2. Verfahren nach Anspruch 1, mit dem Schritt: Erzeugen mehrere Wartungskonzepte (64) für unterschiedliche Komponenten (38), Funktionen (38), Subsysteme (36) oder vor Ort austauschbare Einheiten (40), wobei jedes Wartungskonzept mehrere Fehlermodi (162) und Indikatoren (164) für die Fehlermodi für eine entsprechende Komponente, Funktion, Subsystem oder vor Ort austauschbare Einheit aufweist.
  3. Verfahren nach Anspruch 1, bei dem das Erzeugen des Wartungskonzepts (64) ein Abschätzen von Wahrscheinlichkeiten (128) eines Auftretens der Fehlermodi (162) beinhaltet.
  4. Verfahren nach Anspruch 3, bei dem das Bewerten des Wartungskonzepts (64) ein Ermitteln einer Genauigkeit der Wahrscheinlichkeiten eines Auftretens der Fehlermodi (162) beinhaltet.
  5. Verfahren nach Anspruch 1, bei dem das Wartungskonzept (64) vor dem Schritt des Anwendens bewertet wird, um eine Tauglichkeit des Konzepts, die Fehlermodi (162) zu erfassen und einzugrenzen, zu ermitteln.
  6. Verfahren nach Anspruch 1, bei dem der Schritt des Anwendens des Wartungskonzepts (64) ein Identifizieren der Wartungsmaßnahme (136, 184) aus mehreren Wartungsmaßnahmen auf der Grundlage der Indikatoren (164) und der Eingabedaten (172) umfasst.
  7. Verfahren nach Anspruch 1, bei dem der Schritt des Anwendens des Wartungskonzepts (64) ein Auswählen des Wartungskonzepts (64) aus mehreren Wartungskonzepten auf der Grundlage der Indikatoren (164) und der Eingabedaten (172) umfasst.
  8. Verfahren nach Anspruch 1, bei dem der Schritt des Bewertens des Wartungskonzepts (64) ein Ermitteln einschließt, ob die empfohlene Wartungsmaßnahme (136, 184) das servicebedürftige Ereignis zufriedenstellend angesprochen hat.
  9. Verfahren nach Anspruch 1, mit dem Schritt eines Zuweisens von Kosten (138) für Wartungsmaßnahmen (136, 184), die im Zusammenhang mit jedem Fehlermodus (162) auftreten.
  10. Verfahren nach Anspruch 9, mit dem Schritt eines Hinzufügens eines zusätzlichen Indikators (164), um auf der Grundlage der Kosten (138) eine zusätzliche Fehlermoduseingrenzung vorzusehen.
DE102004015501A 2003-03-28 2004-03-27 Verfahren und Vorrichtung für Wartbarkeit komplexer Systeme Withdrawn DE102004015501A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/402722 2003-03-28
US10/402,722 US20040193938A1 (en) 2003-03-28 2003-03-28 Complex system serviceability method and apparatus

Publications (1)

Publication Number Publication Date
DE102004015501A1 true DE102004015501A1 (de) 2004-10-21

Family

ID=32989781

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102004015501A Withdrawn DE102004015501A1 (de) 2003-03-28 2004-03-27 Verfahren und Vorrichtung für Wartbarkeit komplexer Systeme

Country Status (2)

Country Link
US (1) US20040193938A1 (de)
DE (1) DE102004015501A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107767523A (zh) * 2017-10-27 2018-03-06 上海联影医疗科技有限公司 叫号系统、方法及存储介质

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1679645A1 (de) * 2005-01-10 2006-07-12 Sap Ag Verfahren und Computersystem für die Zuordnung von Gegenständen zu Arbeitsplätzen
US7536284B2 (en) * 2005-08-30 2009-05-19 Lectromechanical Design Company Electrical wire interconnect system risk assessment tool
EP1916621A1 (de) * 2006-10-26 2008-04-30 Hewlett-Packard Development Company, L.P. Anpassen von Computer-Netzwerken
US20090089112A1 (en) * 2007-09-28 2009-04-02 General Electric Company Service Resource Evaluation Method and System
US8965100B2 (en) * 2012-01-20 2015-02-24 The Boeing Company Ultrasonic modeling for inspection of composite irregularities
JP5948257B2 (ja) * 2013-01-11 2016-07-06 株式会社日立製作所 情報処理システム監視装置、監視方法、及び監視プログラム
WO2017129243A1 (en) * 2016-01-28 2017-08-03 Siemens Aktiengesellschaft Method and apparatus for analyzing an investigated complex system
US20170242081A1 (en) * 2016-02-24 2017-08-24 General Electric Company System and method for optimization of recommended service intervals
CN105959374B (zh) * 2016-05-12 2019-05-03 腾讯科技（深圳）有限公司 一种数据推荐方法及其设备
US20190146446A1 (en) * 2017-11-10 2019-05-16 General Electric Company Methods and apparatus to generate an asset health quantifier of a turbine engine
CN109508424B (zh) * 2018-12-17 2020-09-08 中译语通科技股份有限公司 一种基于特征演进的流式数据推荐方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6070155A (en) * 1995-01-12 2000-05-30 Automated Vehicle Anaysis, Inc. Integrated automated analysis and repair
US6901582B1 (en) * 1999-11-24 2005-05-31 Quest Software, Inc. Monitoring system for monitoring the performance of an application
US6609050B2 (en) * 2000-01-20 2003-08-19 Daimlerchrysler Corporation Vehicle warranty and repair computer-networked system
US6370454B1 (en) * 2000-02-25 2002-04-09 Edwin S. Moore Iii Apparatus and method for monitoring and maintaining mechanized equipment

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107767523A (zh) * 2017-10-27 2018-03-06 上海联影医疗科技有限公司 叫号系统、方法及存储介质
CN107767523B (zh) * 2017-10-27 2020-07-14 上海联影医疗科技有限公司 叫号系统、方法及存储介质

Also Published As

Publication number Publication date
US20040193938A1 (en) 2004-09-30

Similar Documents

Publication Publication Date Title
DE102004015504A1 (de) Verfahren und Vorrichtung zur diagnostischen Wahl eines Wartungskonzepts für ein komplexes System
DE102004015503A1 (de) Verfahren und Vorrichtung zum Korrigieren diagnostischer Analysekonzepte in komplexen Systemen
DE102004015400A1 (de) Methode und Einrichtung für die Bewertung der Wartungsfähigkeit von komplexen Systemen
DE60026796T2 (de) Hybrides Diagnosesystem
DE19742446B4 (de) Fehlerdiagnoseverfahren
DE602005004886T2 (de) Automatische Leistungsanalyse und Fehlerbeseitigung
DE69712678T3 (de) Verfahren zur Echtzeitüberwachung eines Rechnersystems zu seiner Verwaltung und Hilfe zu seiner Wartung während seiner Betriebsbereitschaft
DE602005004997T2 (de) Diagnostisches Verfahren und System
DE112010003932B4 (de) Automatische Korrektur einer Anwendung auf der Grundlage des Laufzeitverhaltens
DE102017102651A1 (de) Vorrichtung zum Formulieren von Regeln in einem Prozesssteuerungsnetzwerk
DE102011117803A1 (de) Verfahren für die Wartungsdiagnose- und Wartungsprozedurverbesserung
DE102005046388A1 (de) Modellgestützte Diagnose und Reparatur mittels Ereignisprotokollierung
DE10220938A1 (de) Ein Verfahren und ein System zum Prüfen einer Unternehmenskonfiguration
DE112005003084T5 (de) Automatisiertes Wartungsverfahren und -system zur Fernüberwachung und -diagnose
DE102010038827A1 (de) Verfahren und System für die Fehlervorhersage mit Hilfe eines Agenten
KR20180108446A (ko) Ict 인프라 관리 시스템 및 이를 이용한 ict 인프라 관리 방법
DE102010036757A1 (de) Grafische Randleiste für ein Prozesssteuerungssystem
EP1307816A1 (de) System zur ermittlung von fehlerursachen
DE102010052998A1 (de) Software-zentrierte Methodik für die Überprüfung und Bestätigung von Fehlermodellen
DE112010004420T5 (de) Verfahren und System zur Verbesserung der Ausführungszeit von Software durch Optimierung elnes Leistungsmodells
DE19916055A1 (de) System und Verfahren zur Integration einer Vielzahl diagnosebezogener Informationen
DE112004000432T5 (de) Generierung von Daten für die Kennzeichnung des betrieblichen Zustands von Maschinen
DE102012103089A1 (de) System und maschinenlesbarer Datenträger zur Erstellung von Patientenprognosen
DE102015225144A1 (de) System und Verfahren zur Diagnose von zumindest einer wartungsbedürftigen Komponente eines Geräts und/oder Anlage
DE112010001881T5 (de) Verfahren zum Überwachen von Anlagen über eine installierte Basis zum Verbessern von Design und Leistung der Anlagen

Legal Events

Date Code Title Description
8139 Disposal/non-payment of the annual fee