DE60011142T2

DE60011142T2 - Vorrichtung und verfahren für leistungs- und fehlerdatenanalyse

Info

Publication number: DE60011142T2
Application number: DE60011142T
Authority: DE
Inventors: H. Eric HEDLUND; Edward Nicholas RODDY; Richard David GIBSON; G. Richard BLILEY; E. James PANDER; Ashish Puri; E. Thomas O'CAMB; Howard John LOVELACE; Steven Loncher; James Michael PIERRO
Original assignee: General Electric Co
Current assignee: General Electric Co
Priority date: 1999-10-28
Filing date: 2000-10-26
Publication date: 2005-06-02
Anticipated expiration: 2020-10-27
Also published as: EP1248981B1; EP1248981A1; WO2001031450A1; AU1231601A; ATE268025T1; AU768227B2; CA2389274C; BR0015171A; MXPA02004270A; CA2389274A1; DE60011142D1

Description

HINTERGRUND DER ERFINDUNG
Diese Erfindung bezieht sich auf ein Verfahren sowie eine Einrichtung zum automatischen Analysieren von parametermäßigen Leistungsdaten und von fehlerbezogenen Daten eines Fahrzeugs oder einer Maschine, zum Beispiel von einer Eisenbahnlokomotive oder einer Flotte von Eisenbahnlokomotiven.
Eine Lokomotive stellt ein Beispiel dar für ein komplexes elektromechanisches System, das mehrere komplexe Untersysteme aufweist. Jedes dieser Untersysteme ist aus Komponenten aufgebaut, die mit der Zeit ausfallen werden. Wenn eine Komponente dann tatsächlich ausfällt, ist es häufig schwierig, die Ursache für die ausgefallene Komponente zu ermitteln, weil die Auswirkungen oder Probleme, die der Ausfall auf die Untersysteme hat, oft weder leicht hinsichtlich ihrer Quelle erkennbar noch in typischen Fällen spezifisch bzw. eindeutig sind. Die Fähigkeit zur automatischen Diagnose von Problemen, die in den Untersystemen der Lokomotive aufgetreten sind oder auftreten werden, hat eine positive Auswirkung darauf, die Ausfallzeit einer Lokomotive minimal zu halten. Die Ausfallzeit einer jeden Maschine oder eines jeden Fahrzeugs kann in vorteilhafter Weise durch eine sorgfältige und frühzeitige Diagnose beeinflußt werden.
Es ist weiterhin bekannt, daß ein kostenmäßig effizienter Betrieb einer Eisenbahnflotte oder irgendeiner anderen Fahrzeugflotte die Minimierung von Gleis- bzw. Wegstreckenfehlern sowie der Ausfallzeit der Lokomotive erfordert. Der Ausfall eines wichtigen Fahrzeuguntersystems kann einen ernsten Schaden, teure Reparaturen sowie signifikante betriebsmäßige Verzögerungen verursachen. Eine Panne bei einer sich in Betrieb befindenden Lokomotive ist ein besonders kostenaufwendiger Vorfall, der den Einsatz einer Ersatzlokomotive zum Abschleppen des Zuges und möglicherweise das Außerbetriebnehmen eines Gleissegments erfordert, bis der Zug in Bewegung gesetzt ist. Im Ergebnis ist der einwandfreie Zustand des Lokomotivenantriebs und seiner bestandteilmäßigen Untersysteme von signifikanter Bedeutung.
Frühere Versuche zur Untersuchung von Problemen, sobald sie bei einem Fahrzeug oder einer anderen komplexen Maschine aufgetreten waren, beziehen normalerwei se die Durchführung von Inspektionen durch erfahrenes Personal ein, das eine gründliche individuelle Ausbildung und Erfahren mit den Fahrzeuglokomotiven besitzt. In typischen Fällen benutzen diese erfahrenen Techniker Informationen, die in einem sog. Log aufgezeichnet worden sind. Indem sie diese Aufzeichnungen durchgehen, wenden sie ihre angesammelte Erfahrung und Ausbildung bei der Erfassung der in den Systemen auftretenden Vorfälle in Bezug auf die Probleme an, die diese Vorfälle verursacht haben können. Wenn das Szenario Vorfall-Problem einfach ist, dann arbeitet dieser Lösungsansatz einigermaßen gut. Wenn das Szenario Vorfall-Problem jedoch komplex ist, dann ist es sehr schwierig, irgendwelche mit den Vorfällen in Zusammenhang stehenden Fehler zu diagnostizieren und zu korrigieren.
Derzeit werden auf Computer basierte Systeme zur automatischen Diagnose von Problemen in einem Fahrzeug benutzt, um einige der Nachteile zu überwinden, die damit zusammenhängen, daß man sich vollständig auf erfahrenes Personal stützt. In typischen Fällen benutzt ein auf Computer basiertes System eine Zuordnung bzw. Abbildung (mapping) zwischen den beobachteten Fehlersymptomen und den Problemen der technischen Einrichtung, wobei man Techniken verwendet wie das Nachschlagen in Tabellen, sowie Symptom-Problem-Matrizen und Produktionsregeln. Diese Techniken arbeiten ordentlich für einfache Systeme mit einfachen Zuordnungen zwischen den Symptomen und Problemen. Komplexe Ausrüstungs- und Verfahrensdiagnostiken weisen jedoch nur selten solche einfachen Korrespondenzen auf. Hinzu kommt, daß nicht alle Symptome notwendigerweise vorliegen, wenn ein Problem auftritt, was somit andere Lösungsansätze schwerfälliger macht.
Die oben erwähnten Lösungsansätze erfordern entweder einen beträchtlichen Zeitaufwand, bevor die Fehler diagnostiziert sind, oder sie bieten weniger zuverlässige Ergebnisse, oder sie sind nicht in der Lage, in komplexen Systemen zufriedenstellend zu arbeiten. Es besteht ein Bedarf, schnell und effizient die Ursache von irgendwelchen in den Fahrzeugsystemen auftretenden Fehlern bestimmen zu können, während man gleichzeitig den Bedarf an menschlicher Intervention möglichst gering hält.
Auch gibt es keinen automatischen oder systematischen Mechanismus zur Identifizierung von beginnenden Maschinenproblemen. Statt dessen haben sich üblicherweise die Besitzer bzw. Betreiber auf reguläre Inspektionen und die Beobachtung von Leistungsabweichungen seitens des Bedieners verlassen. Einige kursorische Inspektionsprozesse können wohl durchgeführt werden, während die Maschine oder das Fahrzeug sich im Betrieb befindet; gründlichere Inspektionen erfordern jedoch, daß das Fahrzeug für einige Tage aus dem Dienst genommen wird. Auf jeden Fall stellt eine Ausfallzeit der Maschine oder des Fahrzeugs, sei es zur Inspektion oder zur Reparatur, einen signifikanten betrieblichen Kostenfaktor dar. Die Vermeidung dieser Kosten durch eine genaue Fehlerdiagnose und Vorhersage von potentiellen Fehlern bedeutet eine wichtige Möglichkeit zur Kosteneinsparung für die Eigentümer der Maschinen sowie die Bediener.
Als eine weitere Maßnahme zur Reduzierung der Ausfallzeit hat man einen Schwerpunkt auf den ingenieursmäßigen Konstruktionsvorgang gelegt mit einer Zielsetzung in Richtung auf die Erhöhung der mittleren Zeit zwischen Fehlerauftritten für die Subsysteme und Komponenten. Zwar ist dies sicher eine empfehlenswerte Zielsetzung, es bleibt jedoch für die Eigentümer dabei, ihre Ziele hinsichtlich der Kosteneinhaltung weiter zu verfolgen durch das Sammeln und Überwachen der Echtzeit-Leistungsdaten sowie der fehlerbezogenen Information direkt von dem Fahrzeug und durch die Ausführung von Reparaturen, bevor das Problem eine signifikante Ausfallzeit erfordert.
Das Dokument WO-A-97/13 064 beschreibt ein Diagnosesystem für ein Maschinenmanagementsystem. Ein Diagnose-Planer bestimmt nach Maßgabe eines Reihenfolgewertes (ranking), welches von mehreren Diagnosemodulen den betriebsmäßigen Status einer gegebenen Komponente beurteilen darf. Die Ergebnisse werden bereit gestellt in Form eines 'Kein-Fehler'-Signals oder eines bewerteten Fehlersignals. Das in diesem Dokument vorgeschlagene System weicht von dem durch die vorliegende Erfindung beanspruchten System dadurch ab, daß die Leistungsdaten bei dem genannten Dokument nicht als solche gesammelt werden, sondern daß Diagnosen sowie Aufzeichnungen von diagnosemäßigen Störungs-Codes vorgenommen werden.
KURZE ZUSAMMENFASSUNG DER ERFINDUNG
Allgemein gesprochen, erfüllt die vorliegende Erfindung die zuvor erwähnten Anforderungen, indem sie ein Verfahren bereitstellt zum Analysieren von Echtzeit-Leistungsdaten und zum Identifizieren einer Vielzahl von Fehlern und kritischen Fehlern in Maschinen. Allgemein schließt das Verfahren das Sammeln entsprechender Maschinendaten von einer vorbestimmten Anzahl der Maschinen ein, welche Daten einen Hinweis auf die Leistung über eine vorbestimmte Zeitperiode geben. Das Verfahren schließt ferner entsprechende Identifizierungsschritte ein, die im Rahmen der gesammelten Maschinendaten eine Identifizierung entsprechender Fehler erlauben, die sehr häufig relativ zueinander auftreten, sowie zur Identifizierung innerhalb der am häufigsten auftretenden Fehler von solchen Fehlern, die relativ zueinander eine größere Anzahl von Maschinen beeinträchtigen. Ein Klassifizierungsschritt erlaubt die Klassifizierung der in dem zuletzt genannten Identifizierungsschritt identifizierten Fehler basierend auf einem erwarteten Maschinen-Abnutzungsgrad, der mit den identifizierten Fehlern in Verbindung steht. Ein Speicherschritt erlaubt das Abspeichern von kritischen Fehlern in einer Datenbank, wobei jegliche Fehler hinsichtlich ihrer Wahrscheinlichkeit dafür klassifiziert sind, zu einem drohenden Maschinen-Ausfallfehler zu führen.
Das System enthält ferner Einrichtungen zum Identifizieren innerhalb der gesammelten Maschinendaten von entsprechenden Fehlern, die sehr häufig relativ miteinander auftreten. Weiterhin sind Mittel vorgesehen zum Identifizieren innerhalb der am häufigsten auftretenden Fehler von entsprechenden Fehlern, die relativ miteinander eine größere Zahl von Maschinen beeinträchtigen. Klassifizierungsmittel erlauben eine Klassifizierung der mit den zuletzt genannten Identifizierungsmitteln identifizierten Fehler basierend auf einem erwarteten Maschinenabnutzungsgrad, der mit den identifizierten Fehlern in Verbindung steht. Eine Datenbank ist gekoppelt mit den Klassifizierungsmitteln, um jegliche Fehler zu speichern, die klassifiziert werden als für einen drohenden Maschinenausfall in Frage kommende wahrscheinliche Fehler, wobei die gespeicherten Fehler die meisten kritischen Fehler umfassen.
In einer Anwendung der vorliegenden Erfindung enthält jede Lokomotive in einer Flotte von Eisenbahnlokomotiven eine bordseitige Überwachungseinrichtung zum Sammeln von Echtzeit-Betriebsdaten. Die bordseitige Überwachungseinrichtung sendet Leistungs- und Fehlerdaten auf einer regulären Basis an ein Überwachungs- und Diagnose-Servicecenter, wo die vorliegende Erfindung die empfangenen Daten analysiert. Es können sich bis zu 3000 Lokomotiven in einer Flotte befinden, von denen jede täglich ihre Daten liefert. Eine derart enorme Datenmenge wird leicht einen menschlichen Bediener überfordern. Es ist deshalb notwendig, die Durchführung der Analyse so zu automatisieren, daß die Analyse der Fehler- und parametermäßigen Leistungsdaten von den automatisierten Datenabspeicherungen (data downloads) auf effiziente und produktive Weise erreicht werden kann.
In Übereinstimmung mit der Lehre der vorliegenden Erfindung erfolgt die Planung und Ausführung jeder Fehleranalyse ohne menschlichen Eingriff und basiert auf dynamischen und zeitkritischen Kriterien, die auf die empfangenen Daten angewendet werden. Zum Beispiel könnte ein solches Kriterium die Priorität der in eine Warteschlange (queue) gebrachten Daten sein, die auf ihre Analyse warten. Die vorliegende Erfindung führt in automatischer Weise die Planung, die Prioritätszuteilung und die Aufsicht über die Durchführung einer oder mehrerer Analysen und Untersuchungen zur Analyse der Lokomotivdaten durch. Der Analyse-Planer der vorliegenden Erfindung führt ebenfalls eine on-line Überwachung der heruntergeladenen Daten durch, teilt den in einer Warteschlange für jede Analyse angeordneten Daten Prioritäten zu und stellt sicher, daß alle Vorbedingungen erfüllt sind, bevor die Analyse oder Diagnose ausgeführt wird. In einer Ausführung können zum Beispiel Grenzen hinsichtlich der Anzahl von Vorgängen für jedes Werkzeug vorliegen, die gleichzeitig ausgeführt werden können, und die Grenzen können abhängig sein von der Priorität der Daten. Zum Beispiel gilt eine Grenze für Daten mit normaler Priorität und eine zweite Grenze gilt für Daten mit hoher Priorität. Der Analyse-Planer behält diese Grenzen bei und setzt sie durch. Für den Fall, daß ein Systemausfall auftritt, startet der Analyse-Planer automatisch jedes Analyse-Werkzeug erneut, das in Betrieb war, als der Ausfall auftrat. Im Falle eines Ausfalls eines Analyse-Werkzeugs versucht der automatische Planer erneut die Inbetriebnahme des ausgefallenen Werkzeugs, bis eine vorbestimmte Grenze für die erneuten Versuche erreicht ist.
Im Anschluß an die Ausführung der Analyse erzeugt die vorliegende Erfindung einen 'Problemfall' für jedes Problem oder jede Anormalität, das bzw. die von dem automatisierten Analyseverfahren identifiziert wurde. Um die menschlichen Ressourcen auf die aktuelle Problemlösung zu begrenzen, ist es wünschenswert, die Problemfälle automatisch zu erzeugen. Der Problemfall beinhaltet die Ausgaben von den mehreren Analyse- und Diagnose(programm)werkzeugen und schließt alle relevanten Daten ein, einschließlich der Symptome, der jeweiligen Fehlernatur, der verwandten Leistungsparameter, der Diagnoseinformation sowie der Reparaturempfehlungen, wie sie von dem automatischen Analyseverfahren erzeugt werden. Der Generator für den jeweiligen Problemfall zeigt all diese Information in visueller Form für die Beobachtung durch einen menschlichen Diagnose- und Reparaturexperten an.
Diese Aufgaben werden in vorteilhafter Weise im wesentlichen gelöst durch die Anwendung der Maßnahmen, wie sie in den unabhängigen Ansprüchen niedergelegt sind. Weitere Verbesserungen werden mittels der Unteransprüche vorgesehen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung läßt sich einfacher verstehen und ihre weiteren Vorteile und Anwendungen werden deutlicher, wenn man sie mit Blick auf die Beschreibung der bevorzugten Ausführungsformen und der folgenden Figuren betrachtet. Darin zeigen:
1 eine beispielhafte Maschine, zum Beispiel eine Lokomotive, die leicht von den Lehren der vorliegenden Erfindung Nutzen ziehen kann;
2 die peripheren Geräte, mit denen der Analyse-Planer der vorliegenden Erfindung kommuniziert;
3 eine Ausführung für den Mikroprozessor der vorliegenden Erfindung:
4, 5A, 5B, 6 und 7 Unterprozesse des Analyse-Planers nach der vorliegenden Erfindung;
8 den Prozeß für die Erzeugung eines Falls entsprechend der vorliegenden Erfindung;
9A und 9B Flußdiagramme der Software, welche den Prozeß für die Erzeugung des Falls darstellen;
10, 11, 12, 13, 14 und 15 die Arbeitsweise der in 8 gezeigten Analyse- und Diagnosewerkzeuge;
16 den Prozeß für die Feststellung einer Fallwiederholung; und
17 ein Ablaufdiagramm, das die Identifizierung von kritischen Fehlern darstellt.
DETALLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGEN
1 zeigt eine schematische Darstellung für eine beispielhafte Lokomotive 2. Bei der Lokomotive kann es sich entweder um eine Wechselstrom- oder um eine Gleichstromlokomotive handeln. Die Lokomotive 2 enthält mehrere komplexe Systeme, die jeweils gesonderte Funktionen ausführen. Einige dieser Systeme und deren Funktionen sind nachfolgend aufgelistet. Man beachte, daß die Lokomotive 2 viele andere Systeme enthält, und daß die vorliegende Erfindung nicht auf die hier beschriebenen Systeme beschränkt ist.
Ein Luft- und Luftbremsensystem 4 liefert komprimierte Luft für die Lokomotive, die ihrerseits die komprimierte Luft nutzt, um die (Druck-)Luftbremsen an der Lokomotive und den Wagen dahinter zu betätigen.
Ein als Hilfssystem 5 vorgesehener Wechselstromgenerator versorgt alle Hilfsaggregate. Insbesondere liefert er Energie direkt an einen Hilfsgebläsemotor sowie an einen Entlüftermotor. Andere Anlagen in der Lokomotive werden über einen Frequenzteiler (cycle skipper) gespeist.
Eine Batterie liefert Energie an ein Kurbel- bzw. Anlassersystem 6 zum Starten einer Dieselmaschine für den Betrieb von einem Gleichstrombus sowie von einem HVAC-System. Der Gleichstrombus bzw. die Gleichstrom-Sammelschiene ihrerseits liefert die Spannung für die Aufrechterhaltung eines optimalen Ladungszustandes der Batterie.
Ein internes Verbundskommunikationssystem sammelt, verteilt und zeigt an die Bestandsdaten quer über alle Lokomotiven in dem Verbund (consist).
Ein Führerstand-Signalsystem 7 verbindet das streckenseitige Steuersystem mit dem Zugsteuersystem. Insbesondere empfängt das System 7 codierte Signale von den Schienen über Gleisempfänger, die vorne und hinten an der Lokomotive angeordnet sind. Die empfangene Information wird dazu benutzt, den Lokomotivführer über die Höchstgeschwindigkeit sowie den Betriebsmodus zu informieren.
Ein verteiltes Energiesteuerungssystem liefert die Möglichkeit für die Fernsteuerung von vielfältigen Lokomotivgeräten irgendwo in dem Zug. Es sorgt ebenfalls für die Steuerung der Fahrleistung beim Antrieb und beim Bremsen sowie die Luft(druck)bremsensteuerung.
Ein Maschinenkühlsystem 8 stellt die Mittel bereit, mittels derer die Maschine sowie andere Komponenten Wärme an das Kühlwasser abgeben. Zusätzlich hält es die Wärmezyklen der Maschine möglichst gering, in dem es eine optimale Maschinentemperatur über den gesamten Belastungsbereich aufrecht erhält und verhindert ein Überhitzen in Tunnels.
Ein Zug-Ende-System stellt eine Kommunikation zwischen dem Führerstand der Lokomotive und dem letzten Wagen zum Zwecke einer Notbremsung zur Verfügung, und zwar über eine Funkverbindung.
Ein Gerätebelüftungssystem 9 stellt die Mittel zum Kühlen der Lokomotivanlagen bereit.
Ein Aufzeichnungssystem für Vorfälle zeichnet die von der FRA (Bundesbahnverwaltung) geforderten Daten sowie eingeschränkte bestimmte Daten für eine Bedienerbeurteilung sowie zur Unfalluntersuchung auf. Es kann zum Beispiel bis zu 72 Stunden lang Daten speichern.
Ein Kraftstoff-Überwachungssystem liefert die Mittel zum Überwachen des Kraftstoffpegels und zum Weiterleiten dieser Information an die Besatzung.
Ein beispielhaftes globales Positioniersystem verwendet Satellitensignale, um die genaue Position, die Geschwindigkeit sowie Höhenmessungen an die verschiedenen Steuersysteme zu liefern. Zusätzlich stellt es eine präzise UTC Referenz für das Steuerungssystem zur Verfügung.
Ein mobiles Kommunikationssystem liefert die hauptsächliche Datenverbindung zwischen der Lokomotive und der Strecke über eine geeignete Funkverbindung (zum Beispiel ein 900 MHz Funkgerät).
Ein Antriebssystem 10 liefert die Mittel für die Bewegung der Lokomotive. Es enthält ebenfalls die Fahrmotoren sowie dynamische Bremsmöglichkeiten. Im Einzelnen erhält das Antriebssystem 10 Energie von dem Fahrgenerator und wandelt diese in den Fahrmotoren für die Bewegung der Lokomotive um.
Ein für mehrere Anlagenbereiche gemeinsames System enthält die Kommunikationsgeräte für die Eingabe/Ausgabe, die von mehreren Systemen geteilt wird.
Ein Fahrgeneratorsystem 11 wandelt mechanische Energie um in elektrische Energie, die dann für das Antriebssystem zur Verfügung gestellt wird.
Ein Fahrzeugsteuerungssystem nimmt die Bedienereingaben an und bestimmt den jeweiligen Betriebsmodus der Lokomotive.
Die oben erwähnten Systeme werden überwacht von einem bordseitigen Überwachungssystem 12 (OBM). Das OBM System 12 verfolgt die in den Systemen auftretenden Vorfälle mittels eines Ereignis-Logbuchs bzw. Logs. Die Lokomotive 2 kann als Option ein bordseitiges Diagnosesystem 13 enthalten, wie es in größerem Detail im US Patent No. 5,845,272 beschrieben ist.
2 zeigt einen Analyse-Planer (scheduler) 15 sowie die verschiedenen Tabellen und Datenbanken, mit denen er kommuniziert. Der Analyse-Planer 15 ist als eine in 3 dargestellte Computervorrichtung ausgeführt. Die Elemente der Computervorrichtung sind für Fachleute auf dem Gebiet gut bekannt und enthalten einen Mikroprozessor 16, einen nicht-flüchtigen Speicher 17, einen RAM 18 sowie eine Schnittstelle 19 für die Eingabe/Ausgabe. Die Struktur und Arbeitsweise dieser Geräte sind in jeder Hinsicht konventionell und bekannt.
Zurückkommend auf 2 empfängt ein Modul 20 für das Herunterladen (down load), zum Beispiel von einem bordseitigen Überwachungssystem 12, Leistungs- und Fehlerdaten. Das Modul 20 zum Herunterladen bzw. Abspeichern empfängt die Leistungs- und Fehlerdaten, erzeugt einen Abspeicherfall, der diese heruntergeladenen Daten enthält, gibt den Abspeicherfall als Eingang auf eine Leistungsdatenta belle 21 sowie auf eine Fehlerdatentabelle 22. Die während einer Abspeichersitzung heruntergeladenen Daten für eine gegebene Lokomotive werden automatisch in einem Abspeicherfall gemäß den Anweisungen der vorliegenden Erfindung zusammengestellt. Zu dem Abspeicherfall relevante Information kann später an diesen Abspeicherfall und seine Unterfälle "angehängt" werden. Es wird jedesmal, wenn diese Daten von einer Lokomotive heruntergeladen werden, ein anderer Abspeicherfall erzeugt.
Das Modul 20 für das Herunterladen fügt weiterhin einen Eintrag für eine Abspeicher-Statustabelle 24 hinzu, wenn das Laden von Fehler- oder anderen Daten in die Leistungs- und Fehlerdatentabelle 22 abgeschlossen ist. Der Analyse-Planer 15 überwacht die Abspeicher-Statustabelle 24 und aktiviert die verschiedenen Analyse- und Diagnosewerkzeuge, wie das nachfolgend näher erörtert wird, wenn die von diesen Werkzeugen gebrauchten Daten in der Leistungs- und Fehlerdatentabelle verfügbar sind, oder mit anderen Worten, wenn die Erzeugung des Abspeicherfalls abgeschlossen ist. Der Analyse-Planer 15 löscht Einträge in der Abspeicher-Statustabelle 24, wenn die Werkzeuganwendung für die heruntergeladenen Daten geplant bzw. terminiert worden ist, d.h. wenn ein Eintrag in einer Warteschlange 34 erzeugt worden ist. Bei einer Ausführung besitzt jedes Werkzeug eine einmalige Warteschlange auf, obwohl das in 1 nicht speziell gezeigt ist.
Im Einzelnen gilt, wenn die Abspeicher-Statustabelle 24 anzeigt, daß ein bestimmter Herunterladevorgang von Daten abgeschlossen ist, erzeugt der Analyse-Planer 15 einen Abspeicher-Werkzeugunterfall, d.h. einen Unterfall für den Abspeicherfall, und zwar für jedes Werkzeug, das die heruntergeladenen Daten prozessiert, und schickt dann einen Eintrag von dem Abspeicher-Werkzeugunterfall zu der Warteschlange 34 für dieses spezielle Werkzeug. Die Unterfälle werden in einer Unterfalltabelle 26 gespeichert. Die tatsächliche Anwendung des Werkzeugs für spezifische Daten bekommt eine Priorität zugeordnet aufgrund des Datentyps in der Warteschlange 34 und ebenfalls aufgrund der Zeit, zu der der Eintrag für den Abspeicher-Werkzeugunterfall erfolgt ist. Bestimmte Typen von heruntergeladenen Leistungs- oder Fehlerdaten werden eine höhere Priorität aufweisen als andere. Der Analyse-Planer 10 spaltet gewissermaßen die Werkzeuge auf (spawns), wie nachfolgend erörtert wird. In dem Maße, wie die verschiedenen Analyse-Werkzeuge die heruntergelade nen Daten prozessieren, erzeugen sie ihre eigenen Ausgangsdaten. Jeder Abspeicher-Werkzeugunterfall wird mit diesen Ausgangsdaten von dem zugehörigen Analyse-Werkzeug angereichert, sowie auch die Statusinformation über den Fortschritt im Rahmen der Anwendung des Werkzeugs.
Der Analyse-Planer 15 aktualisiert die Ausführungsinformation in den Abspeicher-Werkzeugunterfällen, wie in der Unterfalltabelle 26 gespeichert. Jeder Abspeicher-Werkzeugunterfall enthält einen Werkzeugstatuseintrag, der den Ausführungsstatus von jedem Werkzeug anzeigt. Zum Beispiel kann ein einzelnes Werkzeug gleichzeitig auf vier verschiedenen Paketen von Leistungs- und Fehlerdaten, d.h. Abspeicherfällen, ablaufen. Jeder dieser vier Abläufe wird sich wahrscheinlich an einem unterschiedlichen Punkt in dem Durchführungsprozeß befinden, und die Durchführung kann bis zu mehrere Minuten erfordern in Abhängigkeit von der zu prozessierenden Datenmenge sowie von dem speziellen Werkzeug. Somit reflektiert der Abspeicher-Werkzeugunterfall den Ablaufstatus von jedem Werkzeug für jede gleichzeitige Ingangsetzung (instantiation) für das Werkzeug. Enthalten unter diesen Statusanzeigern sind: Anwendung nicht gestartet, Werkzeug hat seine Wiederholgrenze überschritten, Werkzeug hat seine Anwendungszeitgrenze überschritten, Anwendung normal abgeschlossen, sowie eine Reihe von sequentiellen Werten, wobei jeder Wert in der Sequenz den aktuellen Punkt auf der Zeitlinie für die Werkzeuganwendung anzeigt. Der Analyse-Planer 15 kann durch Prüfen des Abspeicher-Werkzeugunterfalls in der Unterfalltabelle 26 ermitteln, wann eine bestimmte Werkzeuganwendung abgeschlossen, fehlgeschlagen oder vor dem Abschluß beendet worden ist.
Eine Werkzeuganwendungstabelle 28 enthält einen Eintrag für jedes Werkzeug einschließlich der Betriebsparameter des Werkzeugs, wie zum Beispiel die Anwendungsgrenzen und die Vorbedingungen für die Anwendung. Einer von diesen Parametern setzt eine Grenze hinsichtlich der Zahl von gleichzeitigen Ingangsetzungen für das Werkzeug, wenn eine Anwendung mit normaler Priorität in der Warteschlange als nächstes vorliegt. Es gibt ebenfalls eine separate Grenze für die Ingangsetzung, die anwendbar ist auf Aufgaben in der Warteschlange mit hoher Priorität. Die Werkzeuganwendungstabelle 28 enthält weiterhin verschiedene vorausgesetzte Werteanforderungen, zum Beispiel eine Anforderung, wonach ein bestimmtes Programmwerkzeug ablaufen muß, bevor ein anderes Werkzeug die Daten prozessieren kann. Die Warteschlangen werden überwacht und die Werkzeuge werden aktiviert gemäß diesen gespeicherten Steuerdaten in der Werkzeuganwendungstabelle 28. Wenn die Zahl von Durchführungsaufgaben unter die normale Prioritätsgrenze fällt, wird die (in der Prioritätsrangfolge) nächste Aufgabe in der Warteschlange abgespalten. Wenn sich eine Aufgabe mit hoher Priorität in der Warteschlange befindet, dann wird die Grenze für die normale Priorität ignoriert zu Gunsten der Aufgabe mit hoher Priorität. Solange, wie die Grenze der höheren Priorität nicht überschritten ist, wird die Aufgabe hoher Priorität für die Prozessierung aktiviert.
Eine Konfigurationstabelle 30 speichert Informationen, die angibt, welche Werkzeuge (und welche Versionen davon) ablaufen sollten für Abspeicherfälle von einer spezifischen Eisenbahnlokomotive. Zum Beispiel bedeuten Änderungen in der Versionsnummer des Werkzeugs Änderungen in der Werkzeugsoftware, die das Werkzeug unverträglich machen können mit bestimmten heruntergeladenen Daten. Im Ergebnis ist es erforderlich, daß die heruntergeladenen Daten zuerst zum Beispiel einer Modifikationsumwandlung unterzogen werden, bevor man das Werkzeug auf die Daten zur Anwendung bringt. Die Konfigurationstabelle 30 enthält weiterhin die Dateiposition für die Durchführungsparameter des Werkzeugs.
Jeder Abspeicherfall ist in der Abspeicherfalltabelle 32 gespeichert. Wie oben erörtert, enthält jeder Abspeicherfall bestimmte Leistungs- und Fehlerdaten von einer Lokomotive. In den abgespeicherten Werkzeugunterfällen wird die heruntergeladene Information in ein Paket gebündelt zur Ausführung mittels eines der Diagnose- oder Analyse-Werkzeuge. Die unter jedem Abspeicherfall erzeugten Abspeicher-Werkzeugunterfälle enthalten die von dem Werkzeug zu prozessierenden Leistungs- und Fehlerdaten. Nachdem ein Abspeicher-Werkzeugunterfall erzeugt worden ist und entsprechende Einträge in der Unterfalltabelle 26 gemacht worden sind, schiebt der Analyse-Planer 15 den Abspeicher-Werkzeugunterfall zu einer Warteschlange 34. Von hier wird der Abspeicher-Werkzeugunterfall von dem identifizierten Werkzeug abgearbeitet, wenn die Verarbeitung diesen Punkt in der Warteschlange 34 erreicht. 2 zeigt weiterhin, daß der Analyse-Planer 15 den Ablauf der Werkzeuge steuert, nachdem alle relevante Information verfügbar ist. Dies ist allgemein durch den die Bezugszahl 36 tragenden Block gezeigt und wird in Verbindung mit den Flußdiagrammen der 4–7 im größeren Detail erörtert. Weiterhin wird hier nachfolgend die Arbeitsweise eines Problemfallgenerators 31 erörtert. Sobald ein Abspeicher-Werkzeugunterfall abgeschlossen ist, (d.h. die Verarbeitung der Daten mittels des Werkzeugs ist beendet), schließt der Analyse-Planer 10 sodann diesen Abspeicher-Werkzeugunterfall in der Abspeicherfalltabelle 32.
4 stellt den von dem Analyse-Planer 15 zur Vorbereitung für den Ablauf eines Diagnose- oder Analyse-Werkzeugs ausgeführten Prozeß dar. Die Verarbeitung beginnt bei einem Startschritt 40 und verläuft zu einem Entscheidungsschritt 42, wo die Abfrage vorgenommen wird, ob eine oder mehrere Aufzeichnungen in der Abspeicherstatustabelle 42 anzeigen, daß die Verarbeitung noch nicht im Hinblick auf einen Abspeicherfall eingeleitet worden ist, d.h. auf von der Lokomotive empfangene Leistungs- oder Fehlerdaten. Wenn das Ergebnis des Entscheidungsschritts 42 zutreffend ist, geht die Verarbeitung über zu einem Schritt 44, wo der den Daten mit der höchsten Priorität entsprechende Eintrag für die Verarbeitung ausgewählt wird. Im Schritt 46 lokalisiert der Analyse-Planer 15 den zugeordneten Abspeicherfall in der Abspeicherfalltabelle 32, die notwendige Werkzeugkonfiguration sowie die Ausführungsinformation, und zwar aus der Konfigurationstabelle 30 sowie aus der Werkzeuganwendungstabelle 28. Im Schritt 48 erzeugt der Analyse-Planer 15 die Abspeicher-Werkzeugunterfalleinträge in der Unterfalltabelle 26 (basierend auf den Informationen in der Konfigurationstabelle 30 sowie in der Werkzeuganwendungstabelle 28) und leitet die relevante Information zu der Warteschleife 34. Nachdem jetzt die Information in die Warteschlange eingereiht ist, löscht im Schritt 50 der Analyse-Planer 15 den zugehörigen Abspeicherfalleintrag in der Abspeicherstatustabelle 24. Ein Übergabeschritt 51 stellt sicher, daß die in den Schritten 48 und 50 vorgenommenen Modifikationen gleichzeitig die zugehörigen Tabellen aktualisieren. Die Verarbeitung kehrt sodann zurück zum Entscheidungsschritt 42 zum Auffinden (retrieval) zusätzlicher Abspeicherfälle.
Wenn das Ergebnis von dem Entscheidungsschritt 42 nicht zutrifft, sucht in einem Schritt 52 der Analyse-Planer 15 den Wert für die Ruhezeit von einer Systemparametertabelle 23 von 2 auf und fällt dann, wie im Schritt 53 gezeigt, in einen Ruhezustand. Wenn die Ruhezeit abgelaufen ist, kehrt die Verarbeitung zurück zum Entscheidungsschritt 42, wo Aufzeichnungen in der Abspeicher-Statustabelle 42 erneut geprüft werden.
Die 5A und 5B stellen die Verfahrensverlaufdiagramme für die Software zum Aufspalten des Werkzeugs (tool spawning) dar, welches die Anwendung von jedem der Diagnose- und Analyse-Werkzeuge in Gang setzt. Die Software zur Werkzeugaufspaltung ist eine weitere Softwarekomponente des Analyse-Planers 15 und wird von diesem ausgeführt. Es gibt einen Werkzeugaufspalter für jedes Werkzeug, wie es von dem Analyse-Planer 15 angewendet wird. Die Verarbeitung beginnt bei einem Startschritt 58, wo die spezielle Werkzeugidentifizierung in den Werkzeugaufspaltungsprozeß eingegeben wird. Bei einem Schritt 59 wird die Aufspaltungsruhezeit aufgesucht, und bei einem Schritt 60 werden die Werkzeugausführungsparameter (von der Werkzeuganwendungstabelle 28 sowie von der Konfigurationstabelle 30) an den Werkzeugaufspalter eingegeben. Einer von diesen Parametern ist zum Beispiel die Anzahl der zugelassenen gleichzeitigen Werkzeuganwendungen mit hoher Priorität. Die Verarbeitung geht sodann über zu einem Schritt 61, wo der mit der höchsten Priorität ausgestattete Abspeicher-Werkzeugunterfall ausgewählt wird, für den ein erneuter Versuch erforderlich wird (d.h. wo der Wert des Wiederholkennzeichens 'eins' ist). Ein erneuter Versuch würde zum Beispiel erforderlich sein, wenn das System zusammenbräche, während das Werkzeug Daten des Abspeicher-Werkzeugunterfalls bearbeitete. Das Setzen des Kennzeichens für einen erneuten Versuch wird in Verbindung mit 5 näher erörtert. Die Verarbeitung geht sodann über zu einem Entscheidungsschritt 62, wo der Auswahlzähler geprüft wird. Wenn bei dem Schritt 61 Daten selektiert wurden, dann wird der Auswahlzähler einen von Null verschiedenen Wert aufweisen und die Verarbeitung geht weiter zu einem Schritt 63, wo die Werkzeuganwendung aufgespaltet wird (d.h. das Werkzeug prozessiert die Daten).
Wenn bei dem Schritt 61 keine Daten selektiert waren, weil keine Abspeicher-Werkzeugunterfalleinträge vorlagen, die auf eine erneute Ausführung warteten, ist das Ergebnis des Entscheidungsschritts 62 zutreffend und die Verarbeitung geht weiter zu einem Schritt 64. Bei dem Schritt 64 zählt der Werkzeugaufspalter die Anzahl der Abspeicher-Werkzeugunterfälle, die derzeit unter dem betreffenden Werkzeug ablaufen, und stellt einen Ausführungszählerwert entsprechend dieser Zahl ein. Die Verarbeitung geht dann über zu einem Schritt 65, bei dem der Werkzeugaufspalter in der Warteschlange 34 die mit der hohen Priorität ausgestatteten Abspeicher-Werkzeugunterfälle selektiert, für die alle Voraussetzungen erfüllt sind (einschließlich des Abschlusses des Abspeicherprozesses), die jedoch einen Wiederholkennzeichenwert von Null aufweisen. Bei einem Entscheidungsschritt 66 wird der Auswahlzählerstand von dem Schritt 65 überprüft. Wenn bei dem Schritt 65 ein Abspeicher-Werkzeugunterfalleintrag selektiert war, wird das Ergebnis vom Schritt 66 nicht zutreffen und die Verarbeitung geht weiter zu einem Entscheidungsschritt 67. Hier wird der Zählwert der Ausführung (der die Anzahl der laufenden Abspeicher-Werkzeugfälle darstellt) mit dem gleichzeitigen Grenzwert für die Fälle mit hoher Priorität verglichen. Wenn der letztere Wert größer oder gleich dem vorherigen Wert ist, dann können keine zusätzlichen Werkzeuganwendungen abgespalten werden und die Verarbeitung geht über zum Ruheschritt 68. Man beachte, daß die Ruhezeit für jedes spezifisches Werkzeug zuvor beim Schritt 59 in den Werkzeugaufspalter eingegeben wurde. Nachdem die Ruhezeit abgelaufen ist, kehrt die Verarbeitung zum Schritt 64 zurück. Wenn der Grenzwert für die gleichzeitige Ausübung nicht überschritten ist, erzeugt der Entscheidungsschritt 67 ein zutreffendes Ergebnis und das Werkzeug wird bei einem Schritt 73 aufgespaltet.
Wenn im Schritt 65 keine Abspeicher-Werkzeugunterfälle mit "hoher Priorität" ausgewählt wurden ist das Ergebnis des Entscheidungsschritts 66 zutreffend und die Verarbeitung geht über zu einem Schritt 69. Hier werden die Abspeicher-Werkzeugunterfälle mit normaler Priorität untersucht um zu bestimmen, ob für irgendwelche davon alle Voraussetzungen erfüllt und sie daher für den Ablauf bereit sind. Bei einem Entscheidungsschritt 70 wird der beim Schritt 69 gesetzte Auswahlwert geprüft, und wenn er Null ist, was darauf hinweist, das keine Selektionen im Schritt 69 vorgenommen wurden, geht die Verarbeitung über zum Ruheschritt 71. Nachdem die Ruhezeit abgelaufen ist, geht die Verarbeitung vom Ruheschritt 71 zurück zum Schritt 64.
Wenn der Schritt 69 zu einer Auswahl führte, ist das Ergebnis von dem Entscheidungsschritt 70 unzutreffend und die Verarbeitung geht über zu einem Entscheidungsschritt 72. Hier wird der Zählerstand für die Ausführung verglichen mit dem gleichzeitigen Anwendungsgrenzwert für Abspeicher-Werkzeugunterfälle mit norma ler Priorität. Wenn das Ergebnis zutreffend ist, geht die Verarbeitung über zum Schritt 73, wo der Werkzeuglauf aufgespaltet wird. Wenn das Ergebnis des Entscheidungsschritts 72 unzutreffend ist, ruht der Prozeß, wie das durch einen Ruheschritt 72 angezeigt ist. Nach dem Wiederaufwachen kehrt die Verarbeitung zurück zum Schritt 64. Anschließend an dem Schritt 73 kehrt die Verarbeitung zurück zum Schritt 64, um erneut den Ausführungszähler zu setzen und Fälle für die Werkzeugaufspaltung in den Schritten 65 und 69 zu selektieren.
Der in 6 dargestellte Softwareprozeß für die Werkzeugüberwachung überwacht die Anwendung der verschiedenen mit der vorliegenden Verbindung zusammenhängenden Werkzeuge um sicher zu stellen, daß die Werkzeuganwendung nicht irgendwelche Grenzen für die Werkzeuge überschreitet. Die Verarbeitung beginnt bei einem Startschritt 77 und setzt sich fort zu einem Schritt 78, wo die Überwachungsruhezeit aus der Konfigurationstabelle 30 erhalten wird, und wo ein Wert eingestellt wird, um den einleitenden Durchgang durch den Werkzeugmonitor anzuzeigen. Bei einem Schritt 79 werden die Parameter für die Werkzeuganwendung aus der Werkzeuganwendungstabelle 28 erhalten. Beim Schritt 80 werden die Abspeicher-Werkzeugunterfälle in einer Prioritätsreihenfolge unter diesen Abspeicher-Werkzeugunterfällen ausgewählt, die gerade ausgeführt werden. Vom Schritt 80 geht die Verarbeitung über zu einem Schritt 81, wo der nächste (oder der erste, wie der Fall jeweils liegen mag) Abspeicher-Werkzeugunterfall in der Liste erhalten wird. Bei einem Entscheidungsschritt 82 erfolgt eine Prüfung um zu bestimmen, ob der Abspeicher-Werkzeugunterfall gerade prozessiert wird. Wenn der Abspeicher-Werkzeugunterfall gerade ausgeführt wird, geht die Verarbeitung über zu einem Entscheidungsschritt 83. Wenn dies das erste mal ist, daß der Abspeicher-Werkzeugunterfall prozessiert wird, ist die Entscheidung von dem Entscheidungsschritt 83 zutreffend. Die Verarbeitung verläuft dann weiter zu einem Schritt 84, wo das Vorzeichen für den erneuten Versuch auf 'eins' gesetzt wird und wo der Abspeicher-Werkzeugunterfall zur Ausführung mittels des Werkzeugs freigegeben wird. Wenn es sich hierbei nicht um den ersten Verarbeitungsversuch handelt, ist das Ergebnis des Entscheidungsschritts 83 unzutreffend und in einem Entscheidungsschritt 85 wird der Zählwert für einen erneuten Start (bei dem es sich um einen Wert handelt, der in dem Abspeicher-Werkzeugunterfalleintrag enthalten ist) verglichen mit der Wiederholgrenze. Wenn der Zählwert größer oder gleich der Wiederholgren ze ist, wird die Ausführung bei einem Schritt 86 abgeschlossen und der Unterfall wird aus der Warteschlange entfernt. Wenn die Wiederholgrenze nicht erreicht ist, geht die Verarbeitung von dem Entscheidungsschritt 85 zurück zu dem Schritt 84, und der Unterfall wird in die Warteschlange zur Verarbeitung mittels des Werkzeugs eingereiht.
Wenn der Abspeicher-Werkzeugunterfall derzeit nicht verarbeitet wird, ist das Ergebnis von dem Entscheidungsschritt 82 unzutreffend. Die Verarbeitung geht dann über zu einem Schritt 87, wo die bei der Verarbeitung abgelaufene Zeit errechnet wird. In einem Entscheidungsschritt 88 wird die Verarbeitungszeit verglichen mit der Verarbeitungszeitgrenze. Wenn die Grenze überschritten worden ist, geht die Verarbeitung über zu dem Schritt 86, an dem die Ausführung beendet wird. Immer wenn eine Ausführung beendet wird, wird ein Eintrag erzeugt, der diesen Vorfall dem Systemanwender zur Kenntnis gibt. Zu diesem Zeitpunkt ist eine menschliche Intervention erforderlich, um das Verarbeitungsproblem zu lösen. Es kann zum Beispiel sein, daß die Verarbeitung aufgrund von verfälschten Daten in dem Abspeicherfall keinen Erfolg hatte. Wenn das Ergebnis von dem Entscheidungsschritt 88 unzutreffend ist, führt das Werkzeug weiterhin den Unterfall aus und der Werkzeugüberwachungsprozeß geht zu einem Entscheidungsschritt 89 über. Man beachte, daß die Verarbeitung nach dem Schritt 84 ebenfalls zu dem Entscheidungsschritt 84 übergeht. Beim Entscheidungsschritt 89, wenn das Ende der Liste noch nicht erreicht worden ist, kehrt die Verarbeitung zum Schritt 81 zurück, um den nächsten Abspeicher-Werkzeugunterfall aufzunehmen. Wenn das Ende der Liste erreicht worden ist, wird bei einem Schritt 90 das erste Zeitkennzeichen auf 'nein' gesetzt. Der Werkzeugmonitor ruht dann, wie beim Schritt 91 angegeben. Wenn die Ruhezeit abläuft, kehrt die Verarbeitung zum Schritt 80 zurück, wo erneut Abspeicher-Werkzeugunterfälle aufgesucht werden.
Der Analyse-Planer 15 schließt ebenfalls die Werkzeuganwendung nach der Verarbeitung von allen Abspeicher-Werkzeugunterfällen. 7 zeigt die Softwareschritte für ein Programm zum Schließen eines Abspeicherfalls mittels des Analyse-Planers 15. Die Verarbeitung beginnt bei einem Startschritt 94 und fährt fort zu einem Entscheidungsschritt 95. Hier werden die Abspeicherfälle untersucht um zu entscheiden, ob irgendwelche von ihnen anzeigen, daß sowohl die Fehler- als auch die Parameterabspeicherungen abgeschlossen sind und alle Abspeicher-Werkzeugunterfälle unter dem jeweiligen Abspeicherfall im Anschluß an die Werkzeugverarbeitung des Abspeicher-Werkzeugunterfalls geschlossen worden sind, oder ob das Herunterladen bzw. die Abspeicherung aufgrund eines Kommunikationsproblems fehlgeschlagen ist. Wenn eine von diesen Feststellungen zutreffend ist, geht die Verarbeitung über zu einem Schritt 96, bei dem der Abspeicherfall geschlossen wird. Wenn alle Abspeicher-Werkzeugunterfälle geschlossen worden sind, kann der entsprechende Abspeicherfall geschlossen werden. Ebenso kann, wenn das Herunterladen der Daten von der Lokomotive fehlgeschlagen ist, der Abspeicherfall geschlossen werden. Wenn die Antwort von dem Entscheidungsschritt 95 negativ ist, lädt der Fallabschließer in einem Schritt 97 die Ruhezeit aus der Datenbank herunter. Das Programm zum Schließen des Falles ruht sodann, wie beim Ruheschritt 98 angedeutet ist. Am Ende der Ruhezeit kehrt die Verarbeitung zurück zum Entscheidungsschritt 95. Bei einer Ausführung der vorliegenden Erfindung beträgt die Ruhezeit 24 Stunden.
8 veranschaulicht den von der vorliegenden Erfindung benutzten Prozeß zum Erzeugen eines Analyse- und Reparaturfalls, ansonsten auch als ein Problemfall bezeichnet. Ein Problemfall ist eine Sammlung von Informationen, die relevant sind für eine oder mehrere Leistungsabweichungen oder Fehler. Auf die vorliegende Erfindung angewandt enthält dieser Fall zum Beispiel Ausgangsinformationen von den verschiedenen Analyse- und Diagnosewerkzeugen, Fehlerreparaturcodes, die Identifikation von kritischen Fehlern sowie Anomalie-Codedaten, die mit dem heruntergeladenen bzw. abgespeicherten Fall in Verbindung stehen. Im Unterschied zu dem Problemfall enthält der Abspeicherfall die Leistungsparameterinformation, die von der Lokomotive oder, bei anderen Ausführungen, von der Maschine oder dem Fahrzeug heruntergeladen wurden. Der Problemfall enthält ebenfalls Reparatur- und Wartungsvorschläge, und zwar wiederum wie sie von den Analyse- und Diagnosewerkzeugen bestimmt werden. All diese Fallinformation ist für einen Anwender verfügbar, bei dem es sich um jemanden handelt, der auf dem Gebiet des Lokomotivenbetriebs, der Fehler und Reparaturen Kenntnisse besitzt. Der Benutzer sieht den Fall durch, um die Genauigkeit der darin präsentierten Information festzustellen und kann darüber hinaus zusätzliche Informationen anhängen. Der Bediener kann zum Beispiel auf seiner Erfahrung basierende Reparaturvorschläge hinzufügen. Sobald der Problemfall vervollständigt ist, sendet der Bediener den Fall zu dem Wartungs- und Servicepersonal der Eisenbahn. Dies kann erfolgen durch einfaches Anrufen bei der Eisenbahn oder indem man den Fall mittels elektronischer Post zuschickt. Die Zielsetzung besteht darin, den Problemfall für die Eisenbahn bereitzustellen, so daß die darin enthaltenen Reparatur- und Wartungsvorschläge in zeitgerechter Weise implementiert werden können, um eine Lokomotivenpanne zu verhindern oder um eine außer Dienst gestellte Lokomotive zu der Flotte zurückzuholen.
Die meiste Zeit ist die Verarbeitung eines gegebenen Abspeicherfalls ereignislos und es gibt keine bemerkenswerten Anomalien oder Fehler. in solchen Fällen ist kein Problemfall erforderlich und es werden der Abspeicherfall sowie die Abspeicher-Werkzeugunterfälle aufgehoben, um dies im Journal festzuhalten. Wenn jedoch eines oder mehrere der Analyse-Werkzeuge eine anomale Bedingung oder einen Fehler feststellt, dann wird ein Problemfall erzeugt, der dazu dient, all die Ausgangsdaten von allen Analyse-Werkzeugen zu sammeln und zusammenzufassen.
8 zeigt eine Lokomotive, die drei verschiedene Typen von Informationen für ein System zur Erzeugung eines Problemfalls zur Verfügung stellt, das entsprechend den Maßnahmen dieser Erfindung aufgebaut ist. Wie in größerem Detail in dem oben zitierten anwendbaren Patent mit dem Titel "On board Monitor for a Railroad Locomotive" (bordseitige Überwachung für eine Eisenbahnlokomotive) erörtert ist, erzeugen bestimmte schwere Fehler in der Lokomotive unmittelbar einen Heimruf (wie durch die Bezugszahl 101 bezeichnet) zu dem Überwachungs- und Diagnose-Servicecenter, wo das System zur Erzeugung eines Problemfalles angesiedelt ist. Diese Fehler sind entweder von schwerwiegender Natur oder erfordern eine unmittelbare Beachtung und erzeugen somit direkt einen Problemfall, wie das durch den Schritt 102 zur Erzeugung eines Falles angegeben ist. (Vergleiche ebenfalls den Fallgenerator 37 in 1). Um den Problemfall zu erzeugen, leitet der Prozeß für den Heimruf ein Abspeichern der Fehlerdaten sowie ein Abspeichern der überwachten Parameter ein, wie im Schritt 104 gezeigt ist. Der Problemfall wird dann in dem Schritt 102 erzeugt. Später, nachdem die Fehlerinformationen sowie die Informationen hinsichtlich der überwachten Parameter von den Diagnosewerkzeugen analysiert worden sind, werden deren Ergebnisse wahrscheinlich zu dem durch die Heimrufsequenz erzeugten Problemfall hinzugefügt werden. Es ist jedoch möglich, daß auch ein neuer Problemfall erzeugt werden kann, der nur aus den heruntergeladenen Daten abgeleitet ist.
Wie oben in Verbindung mit dem Analyse-Planer 15 erörtert wurde, zeigt ein Schritt 106 das Herunterladen bzw. Abspeichern der Fehlerdaten von der Lokomotive zu dem Überwachungs- und Diagnosecenter, wo die Analyseverarbeitung erfolgt. In einer Ausführung werden die Fehlerdaten mindestens auf täglicher Basis heruntergeladen. Es ist jedoch möglich, daß das keine Fehlerdaten herunterzuladen sind und in diesem Fall die Fehlerwerkzeuge nicht zum Zuge kommen, da es keine zu analysierenden Eingangsdaten gibt. Sobald die Fehlerdaten abgespeichert sind, geht die Verarbeitung über zu einem Schritt 108, wo der Analyseplanungsprozeß ausgeführt wird, wie das oben in Verbindung mit dem Analyse-Planer 10 erörtert wurde. In den Schritten 110, 112, 114 und 116 werden jeweils die Werkzeuge für die Fall-basierte Schlußfolgerung (CBR) (case based reasoning), für das sog. Bayes Annahmennetzwerk (BBN) (Bayesian belief network), für die Fehlerklassifikation bzw. für die Anomaliefeststellung des Datenpakets (DPAD) (data packet anomaly detection) zum Einsatz gebracht. Bei diesen Werkzeugen handelt es sich um Beispiele für Fehler- und Datenanalyse-Werkzeuge, die in Verbindung mit der vorliegenden Erfindung eingesetzt werden können. Fachleute auf diesem Gebiet wissen, daß andere ähnliche Analyse-Werkzeuge zur Verfügung stehen. Diese Werkzeuge, auf die allgemein durch den Prozeßschritt 36 in 2 Bezug genommen worden ist, werden in größerem Detail nachfolgend erörtert. Obwohl nicht in 8 gezeigt, gibt es eine Datenwarteschlange, die mit jedem der dargestellten Werkzeuge in Verbindung steht. Diese Warteschlangen halten die Daten solange, bis das Werkzeug für den Einsatz zur Verfügung steht. Im wesentlichen analysiert jedes Werkzeug die Daten auf der Basis verschiedener Regeln und Maßsysteme, unter Einschluß zurückliegender Fälle (Fehler, Reparaturen und Information zu Betriebsparametern) sowie von Systemen mit sog. künstlicher Intelligenz, um die Natur des Fehlers zu ermitteln und um spezielle Reparaturen (über einen Reparaturcode) festzustellen, die zur Behebung des Fehlers implementiert werden können. Die Werkzeuge können ebenfalls beginnende Probleme innerhalb der Lokomotive feststellen und erlauben somit der Eisenbahn, Korrekturmaßnahmen vorzunehmen, bevor das Problem schwerwiegender wird.
Obwohl die Werkzeuge in 7 in einer parallelen Weise gezeigt sind, wie das für Fachleute auf diesem Gebiet bekannt ist, ist dies kein zwingendes Erfordernis. Andere Ausführungen der vorliegenden Erfindung schließen Alternativen bei der Ausführung ein. Die Werkzeuge können zum Beispiel seriell oder parallel angewendet werden, nachdem der Abspeicherfall erzeugt worden ist (d.h. alle relevanten Daten für die Werkzeuganwendung zu Verfügung stehen) und nachdem jeder der Abspeicher-Werkzeugunterfälle erzeugt worden ist, oder es kann jedes Werkzeug unabhängig eingesetzt werden, nachdem der Abspeicher-Werkzeugunterfall für dieses spezielle Werkzeug zur Verfügung steht. Nachdem alle Werkzeuge die Daten verarbeitet haben, wird der mittels der Bezugszahl 118 veranschaulichte Schritt zur Ermittlung der Fallwiederholung ausgeführt. Schließlich kann jedes Werkzeug unabhängig arbeiten, nachdem sein Abspeicher-Werkzeugunterfall vervollständigt ist und dann unmittelbar den Schritt 118 zur Feststellung der Fallwiederholung ausführen. Die Wahl einer dieser Alternativen ist für den wesentlichen Schutzbereich oder die Funktion der vorliegenden Erfindung nicht von entscheidender Bedeutung.
Die Werkzeugaufspaltungskomponente (tool spawner component) der vorliegenden Erfindung (dargestellt in den 5A und 5B) steuert die Ausführungsfolge der in 8 gezeigten Werkzeuge. Natürlich kann ein Werkzeug nicht zur Anwendung kommen, ehe nicht die voraussetzungsgemäße Information gesammelt worden ist, d.h. bis der Abspeicher-Werkzeugunterfall vollständig ist. Die in 2 dargestellte Werkzeuganwendungstabelle 28 speichert die Bedingungen, die vorliegen müssen, bevor ein bestimmtes Werkzeug zum Einsatz kommen kann. Bei dem Werkzeug zum Feststellen der Fallwiederholung (vgl. Bezugszahl 118 von 8) handelt es sich um ein zusätzliches Werkzeugzeug nach der vorliegenden Erfindung, für das Information in der Werkzeuganwendungstabelle 28 enthalten ist. Das Werkzeug 118 zur Feststellung der Fallwiederholung wird eingesetzt, um wiederholte Fälle festzustellen, nachdem eines oder mehrere der anderen Analyse-Werkzeuge eingesetzt waren. Die Werkzeuge zur Feststellung der Fallwiederholung werden nachfolgend in Verbindung mit den 9A und 9B näher erörtert.
Immer wenn ein neuer Problemfall erzeugt wird, wie durch den Schritt 102 in 8 angezeigt ist, werden bestimmte Informationen in die Fallfelder eingetragen, um den Anwendungsfachmann im Servicecenter für die Überwachung und Diagnose bei der Analyse des Problemfalls zu unterstützen. Die Informationen in den Fallfeldern können enthalten: Fehlercodes und Beschreibungen von den Systemen, auf die sie hinweisen, Reparaturcodes und Beschreibungen der angegebenen Reparaturen, Anomaliecodes und Beschreibungen der angezeigten Warnungen, überwachte Parameterwerte, die mit den Fehlern, Reparaturen und Anomalien im Zusammenhang stehen, Wahrscheinlichkeits- und Gewichtungsfaktoren, die mit den angegebenen Codes im Zusammenhang stehen (wobei die Gewichtungsfaktoren die Wahrscheinlichkeit angeben, daß die angegebene Reparatur den angezeigten Fehler beheben wird), das Datum, die Zeit, während der die Daten gesammelt wurden sowie die Nummer der Eisenbahnlokomotive, von der die Daten gesammelt wurden.
Zurückkommend auf 8 werden zusätzlich zu den Fehlerdaten, deren Abspeichern im Schritt 106 dargestellt ist, weiterhin Daten hinsichtlich der Leistungsparameter von der Lokomotive heruntergeladen, wie im Schritt 124 angegeben ist. Die Prozessierung seitens des Analyse-Planers (vgl. Schritt 126) erfolgt, wie in Verbindung mit den 2–7 erörtert, wenn das Herunterladen vollständig ist. Auf den Schritt 126 folgt die Anwendung des Werkzeugs zur Feststellung von Anomalien (gezeigt im Schritt 128) sowie der Ablauf eines Trendwerkzeugs (dargestellt durch einen Schritt 130). Sodann läuft bei dem Schritt 118 das Programm zur Feststellung der Fallwiederholung ab. Falls notwendig, wird bei dem Schritt 102 ein Fall erzeugt, wie oben erörtert.
Die Flußdiagramme der 9A und 9B zeigen den Algorithmus zum Erzeugen eines Falls gemäß der vorliegenden Erfindung, indem man die Merkmale des Schrittes 118 (Ablauf der Feststellung für die Fallwiederholung) mit dem Schritt 102 (Erzeugen eines Problemfalls) kombiniert. Die Verarbeitung beginnt bei einem Schritt 160, der den Prozeß zum Herunterladen bzw. Abspeichern der Daten zeigt. Von dem Schritt 160 geht die Verarbeitung weiter sowohl zu einem Schritt 162 als auch zu einem Schritt 164. Beim Schritt 162 werden die Werkzeuge für die Fall-basierte Schlußfolgerung (CBR), für das Bayes Annahmennetzwerk (BBN) sowie für Datenpaketanomalien (DPAD) angewendet, um einen Problemfall zu entwickeln und vorteilhafterweise, um Reparaturvorschläge für diesen Problemfall zu entwickeln. Die Ausführung dieser Werkzeuganwendungen wird nachfolgend im Detail erörtert. Beim Schritt 162 werden diese Werkzeuge unter Einsatz ihrer normalen Rückschauzeitpe riode angewendet. Wie nachfolgend weiter erörtert wird, ist die Rückschauzeit die von der Gegenwart bis zu einem Punkt in der Vergangenheit gemessene Zeitperiode, während welcher Daten von dem Werkzeug gesammelt werden. In einem Beispiel beträgt zum Beispiel die Rückschauzeit sieben Tage. Das Werkzeug wird deshalb Fehlerdaten, die während der letzten sieben Tage aufgetreten sind, analysieren in einem Versuch zum Klassifizieren der Fehler und zum Entwickeln von Reparaturvorschlägen. Vom Schritt 162 geht die Verarbeitung weiter zu einem Entscheidungsschritt 166 zum Feststellen, ob irgendwelche Reparaturvorschläge von Seiten der fallbezogenen Schlußfolgerung erzeugt worden sind, oder von dem Bayes Annahmennetzwerk oder von dem Werkzeug zum Feststellen von Datenpaketanomalien. Wenn keine solchen Reparaturen vorgeschlagen wurden, dann ist diese Stufe der Verarbeitung abgeschlossen, wie beim Schritt 168 dargestellt. Wenn Reparaturen vorgeschlagen wurden, geht die Verarbeitung von dem Entscheidungsschritt 166 über zu dem anderen Entscheidungsschritt 170, wo der Prozeß feststellt, ob irgendwelche geschlossenen oder vorgeschlagenen Problemfälle existieren. Geschlossene Fälle sind solche, für die von Seiten der Eisenbahnbehörde) die Reparaturvorschläge implementiert worden sind. Vorgeschlagene Fälle sind solche, wo die Reparaturvorschläge an die Eisenbahn gesandt worden sind und somit in gewisser Weise nicht mehr länger für Änderungen oder Zusätze durch das Fachpersonal beim Servicecenter für die Überwachung und Diagnose offen sind. Nur offene Fälle können mit Informationen aus der momentanen Anwendung der Analyse- und Diagnosewerkzeuge angereichert werden. Wenn es keine geschlossenen oder vorgeschlagenen Fälle gibt, geht die Verarbeitung über zum Schritt 172 wo die von dem Werkzeug vorgeschlagenen Reparaturen zur einer Reparaturliste, in den 9A und 9B durch die Bezugszahl 174 angegeben, hinzugefügt werden.
Wenn existierende geschlossene oder vorgeschlagene Fälle vorhanden sind, dann geht die Verarbeitung vom Entscheidungsschritt 170 weiter zu einem Entscheidungsschritt 180. Der Entscheidungsschritt 180 stellt fest, ob irgendwelche der vorgeschlagenen Reparaturen identisch sind mit Reparaturen in geschlossenen oder vorgeschlagenen Problemfällen, die innerhalb des Zeitrahmens für die Rückschau erzeugt wurden. Wenn es keine derartigen identischen Reparaturen gibt, kehrt die Verarbeitung zurück zum Schritt 172, wo diese Reparaturen zu der Reparaturliste hinzugefügt werden, wo sie später zum Erzeugen eines Problemfalles benutzt werden können. Wenn alle Reparaturen identisch sind mit Reparaturen in geschlossenen oder vorgeschlagenen Problemfällen, dann ist es nötig, die Rückschauzeit so zu ändern, das lediglich solche Daten in die Werkzeuganalyse einbezogen werden, die nach dem jüngsten vorgeschlagenen oder abgeschlossenen Fall gesammelt wurden. Auf diese Weise stellt der Prozeß sicher, daß nur Parameter- und Fehlerdaten, die nach der jüngsten Reparaturempfehlung gesammelt worden sind, einen neuen Problemfall erzeugen können, weil die für die Erzeugung eines früheren geschlossenen oder vorgeschlagenen Problemfalles benutzten Daten nicht mehr länger relevant sind für die Erzeugung von neuen Problemfällen. Wenn seitens der Eisenbahn noch keine vorgeschlagene Reparatur ausgeführt wurde, dann wird man dieselbe Art von Fehlern während dem nächsten Herunterladen bzw. Abspeichern von Fehler- und Leistungsinformationen sehen, was zu einer Erzeugung von denselben Reparaturvorschlägen führt. Der Prozeß zur Feststellung von Fallwiederholungen (vgl. Bezugszeichen 118 von 8) wird sodann den aktuellen vorgeschlagenen Problemfall mit den existierenden vorgeschlagenen Problemfällen kombinieren. Dieser Wechsel des Zeitintervalls für die Rückschau ist gezeigt in einem Schritt 182, wo die Rückschauperiode so geändert wird, daß sie unmittelbar nach dem jüngsten vorgeschlagenen oder geschlossenen Fall beginnt. Bei einem Schritt 184 werden erneut die Werkzeuge für die Fall-basierte Schlußfolgerung, für das Bayesian Annahmennetzwerk sowie für die Datenpaketanomalien mit dem modifizierten Rückschauparameter in Gang gesetzt.
Bei einem Entscheidungsschritt 186 stellt der Prozeß fest, ob irgendwelche Reparaturen im Verlauf der Werkzeuganwendung beim Schritt 184 vorgeschlagen wurden, d.h. basierend auf dem erneuten Anwenden des Werkzeugs unter Benutzung der neuen Rückschauperiode. Wenn keine Reparaturen empfohlen waren, dann ist diese Stufe der Verarbeitung vollständig, wie beim Schritt 190 gezeigt. Wenn es irgendwelche vorgeschlagenen Reparaturen gibt, müssen sie zu der Reparaturliste hinzugefügt werden, wie beim Schritt 188 dargestellt ist.
Zurückkommend auf den Schritt 160 zum Herunterladen der Daten werden beim Schritt 164 die Werkzeuge zur Anomaliefeststellung (AD) sowie zur Anomalietrendfeststellung in Gang gesetzt. Ebenfalls werden beim Schritt 196 die Werkzeuge für die Fehlerklassifikation und die Anomaliefeststellung angewendet. Alle gefundenen Anomalien werden im Schritt 198 zu einer Anomalieliste 200 hinzugefügt.
Von dem Schritt 164 geht die Verarbeitung nach der Anwendung des Werkzeugs für die Trendanomalie weiter zu einem Entscheidungsschritt 202 um festzustellen, ob irgendwelche Anomalien empfohlen wurden. Wenn keine empfohlen wurden endet die Verarbeitung bei einem Schritt 204. Wenn Anomalien gefunden und empfohlen wurden, geht die Verarbeitung weiter zu einem Entscheidungsschritt 206, wo, wie zuvor, der Prozeß feststellt, ob irgendwelche existierenden oder vorgeschlagenen Problemfälle offen sind. Wenn keine solche Problemfälle offen sind, geht die Verarbeitung weiter zu einem Schritt 208, wo die neuen Anomalien zu der Anomalienliste 200 hinzugefügt werden. Wenn es existierende geschlossene oder vorgeschlagene Problemfälle gibt, dann fährt die Verarbeitung vom Schritt 206 fort zu einem Entscheidungsschritt 210. Hier wird eine Feststellung getroffen, ob die festgestellten Trendanomalien identisch sind mit irgendwelchen Trendanomalien in geschlossenen oder vorgeschlagenen Problemfällen. Wenn es keine solchen Übereinstimmungen gibt, geht die Verarbeitung erneut weiter zum Schritt 208, wo die Trendanomalien zur der Anomalienliste hinzugefügt werden. Wenn eine oder mehrere der Anomalien identisch sind mit aufgelisteten Anomalien in geschlossenen oder vorgeschlagenen Problemfällen, geht die Verarbeitung weiter zu einem Schritt 212, wo das Werkzeug für den Anomalientrend erneut in Gang gesetzt wird, und zwar ohne Benutzung der Statusdatei, welche betriebliche Trends in der Vorgeschichte speichert. Dieser Prozeß des erneuten in Gang Setzens der Werkzeuge ohne die Statusdateien beseitigt den Effekt von Anomalien, die mittels früherer vorgeschlagener oder geschlossener Fälle hätten adressiert werden sollen. Nachdem das Anomalienwerkzeug erneut in Gang gesetzt ist, wird bei einem Entscheidungsschritt 214 eine Feststellung getroffen, ob irgendwelche Anomalien festgestellt wurden. Wenn keine festgestellt wurden, endet die Verarbeitung beim Schritt 216. Wenn Anomalien festgestellt wurden, werden diese zu der Anomalienliste hinzugefügt, und zwar mittels der Bearbeitung durch einen Schritt 208.
Nachdem Reparaturen zu der Reparaturliste 174 und Anomalien zu der Anomalienliste (dargestellt durch eine Bezugszahl 200) hinzugefügt sind, geht die Verarbeitung weiter zu einem Entscheidungsschritt 222. Hier stellt der Prozeß fest, ob es irgend welche offenen Problemfälle gibt. Wenn es zu diesem Zeitpunkt keine offenen Problemfälle gibt, wird ein neuer Fall in einem Schritt 224 erzeugt und die Verarbeitung endet bei einem Schritt 226. Der neue Problemfall enthält alle Anomalien von der Anomalienliste 200 sowie alle Reparaturen von der Reparaturliste 174.
Alternativ gilt, wenn es offene Problemfälle gibt, muß festgestellt werden, ob die Reparaturen oder Anomalien in einem Entscheidungsschritt 230 dazu addiert werden können. Hier wird festgestellt, ob es irgendwelche offenen Problemfälle gibt, die weniger als x Stunden alt sind, wobei x ein von dem Anwender zugeteilter Schwellenwert ist. Wenn ein solcher offener Problemfall verfügbar ist, geht die Verarbeitung zu einem Schritt 232 über, wo alle die Anomalien und Reparaturen zu der Reparaturliste für diesen Problemfall hinzugefügt werden. Ebenfalls wird der Abspeicherfall, von dem die Fehler und/oder Anomalien abgeleitet wurden, als ein (logisches) Kind zu dem offenen Problemfall in Verbindung gebracht. Es können dieselben Lokomotivensymptome in mehrfachen Abspeicherungen über viele Tage hin erscheinen und alle solche Abspeicherungen sollten mit demselben offenen Problemfall verbunden werden.
Wenn es keine offenen Fälle gibt, die weniger als x Stunden alt sind, geht die Verarbeitung vom Entscheidungsschritt 230 über zu einem Entscheidungsschritt 234 zur Feststellung, ob es irgendwelche Reparaturen in der Reparaturliste 174 gibt. Wenn dort keine sind, fährt die Verarbeitung fort mit dem Entscheidungsschritt 236, bei dem festgestellt wird, ob alle Anomalien in einem offenen Fall gefunden wurden. Wenn die Antwort nein ist, geht die Verarbeitung weiter zu einem Schritt 238, wo ein neuer Fall erzeugt wird, der alle Anomalien enthält. Die Verarbeitung endet sodann bei dem Schritt 226. Wenn alle Anomalien bereits in einem offenen Fall gefunden werden, geht die Verarbeitung vom Entscheidungsschritt 236 weiter zu einem Schritt 242, wo der Abspeicherfall, von dem die aktuellen Anomalien abgeleitet wurden, als ein (logisches) Kind von diesem offenen Problemfall angebunden wird.
Zurückkommend auf den Entscheidungsschritt 234 gilt, wenn Reparaturen in der Reparaturliste 174 vorliegen, geht die Verarbeitung weiter zu einem Entscheidungsschritt 244. Hier wird festgestellt, ob alle Reparaturen identisch zu denen in einem offenen Problemfall sind. Wenn das eine zutreffende Aussage ist, kehrt die Verar beitung zurück zum Schritt 242, wo der Abspeicherfall als ein (logisches) Kind zu dem offenen Problemfall in Verbindung gebracht wird. Wenn all die Reparaturen nicht identisch sind mit denen in einem offenen Problemfall, geht die Verarbeitung von dem Entscheidungsschritt 244 weiter zu dem Schritt 224, wo ein neuer Problemfall erzeugt wird. Die Verarbeitung endet sodann bei dem Schritt 226.
10 stellt die Betriebscharakteristiken des durch die Bezugszahl 299 gekennzeichneten Werkzeugs für die Fall-basierte Schlußfolgerung dar. Im Zusammenhang mit dem Werkzeug der Fall-basierten Schlußfolgerung handelt es sich bei einem "Fall" um eine Sammlung von Fehlern, Anomalien, vorgeschlagenen Reparaturen sowie von Informationen hinsichtlich der Betriebsparameter, die angesammelt worden sind zum Zwecke des Vergleichs mit anderen "Fällen", um eine vorgeschlagene Reparatur zur Korrektur des Fehlers zu bestimmen. Wie oben erörtert, benutzt das Werkzeug für die Fall-basierte Schlußfolgerung beim ersten Durchgang eine standardmäßige Rückschauperiode von sieben Tagen. Dies kann modifiziert werden für nachfolgende Anwendungen, und zwar wie ebenfalls oben erörtert, in Abhängigkeit davon, ob es irgendwelche Reparaturen gibt, die identisch sind zu den von dem Werkzeug für die Fall-basierte Schlußfolgerung vorgeschlagenen Reparaturen in einem geschlossenen oder vorgeschlagenen Fall. Das Werkzeug für die Fall-basierte Schlußfolgerung analysiert die Fehlerdaten sowie deren Kombinationen unter Verwendung von Informationen aus der Fallbasis 300 für die Fall-basierte Schlußfolgerung (CBR).
Die Konfigurationstabelle 30 (vgl. 2) stellt von dem Werkzeug 299 für die Fall-basierte Schlußfolgerung die jeweilige Version fest, die ablaufen soll, und zwar basierend auf der Lokomotivennummer, von der die Fehler- sowie die Betriebsparameterdaten genommen wurden. Die Bezugszahl 304 stellt die Eingangsinformation hinsichtlich der Fehler sowie der verwandten Betriebsparameter für das Werkzeug 299 für die Fall-basierte Schlußfolgerung dar. Die Fehlerdaten decken lediglich die laufende Rückschauperiode ab und sind hinsichtlich ihres Rauschens reduziert. Bei der Rauschverringerung handelt es sich um den Prozeß des Eliminierens von bekannten Fehlern in der Lokomotive. Zum Beispiel gilt, wenn sich die Lokomotive im Leerlaufzustand befindet, können bestimmte gemessene Parameter jenseits einer vorher etablierten Schwelle liegen und daher fälschlicherweise das Auftreten eines Fehlers anzeigen.
Die Konfigurationstabelle 30 liefert ebenfalls die Wahrscheinlichkeitsschwelle, die von dem Werkzeug für die Fall-basierte Schlußfolgerung als eine Wahrscheinlichkeitsgrenze für empfohlene Reparaturen benutzt wird. Wenn das Werkzeug für die Fall-basierte Schlußfolgerung feststellt, daß die Wahrscheinlichkeit, mit der eine bestimmte Reparatur einen Fehler beseitigt, über einer Schwelle für den Wahrscheinlichkeitswert liegt, dann wird diese Reparaturen (in der Form eines Reparaturcodes) von dem Werkzeug 299 für die Fall-basierte Schlußfolgerung gemeldet. Das Werkzeug 299 für die Fall-basierte Schlußfolgerung teilt den Reparaturvorschlägen Prioritäten zu und meldet die fünf ersten Reparaturcodes, wie das durch die Bezugszahl 306 gezeigt ist. Im Anschluß an die Verarbeitung durch das Werkzeug 299 für die Fall-basierte Schlußfolgerung wird das System den Prozeß zur Feststellung der Fallwiederholung in Gang setzen (vgl. Bezugszeichen 118 in 8).
11 stellt das Werkzeug 310 für das sog. Bayes Annahmennetzwerk dar. Jede Version des Werkzeugs 310 für das Bayes Annahmennetzwerk (BBN) benutzt eine spezielle Regelbasis, wie das mit dem Bezugszeichen 314 dargestellt ist. Die speziell ausgewählte Konfiguration basiert auf der Eisenbahnnummer. Ein Bezugszeichen 316 zeigt eine Tabelle, die von dem Werkzeug 310 für das sog. Bayes Annahmennetzwerk festgestellte Ursachen mit speziellen Reparaturen für einen Problemfall verbindet. Die Regelbasis 314 für das Bayes Netzwerk identifiziert weiterhin die für die Zuteilung von Prioritäten für die Reparaturen verwendeten Reparatur-Wahrscheinlichkeitsschwellen. Wie das Werkzeug 299 für die Fall-basierte Schlußfolgerung benutzt auch das Werkzeug 310 für das sog. Bayes Annahmennetzwerk in einer Ausführung eine siebentägige Rückschau. Diese Rückschau wird modifiziert (wie in Verbindung mit den 9A und 9B erörtert), um die Auswirkungen von geschlossenen oder vorgeschlagenen Fällen zu eliminieren. Der Ausgang von dem Werkzeug 310 für das Bayes Annahmen-Netzwerk sind die obersten drei Reparaturcodes. Nachdem das Werkzeug 310 für das Bayes Annahmen-Netzwerk abläuft, setzt das System das Werkzeug für die Feststellung der Fallwiederholung in Gang, wie das mit dem Bezugszeichen 118 in 8 dargestellt ist.
12 stellt das Werkzeug 326 für die Fehlerklassifikation dar. Dieses Werkzeug erhält seinen Eingang aus dem Fehlerlogbuch von der laufenden Abspeicherung (download), und zwar in gleicher Weise wie die zuvor erörterten Werkzeuge, wie das an Hand der Bezugszahl 328 gezeigt ist. Es gibt keine mit der Anwendung des Werkzeugs 326 für die Fehlerklassifikation zusammenhängende Rückschauperiode. Ein weiterer Eingang für das Werkzeug 326 für die Fehlerklassifikation ist eine Tabelle 330 für die Fehlerservicestrategie. Diese Tabelle enthält eine Liste von typischen Fehlern, die in einer Eisenbahnlokomotive gefunden wurden sowie jeweils eine Prioritätsreihenfolge. Jeder Fehler in der Tabelle ist ausgewiesen mit einem Indikatorwert als entweder ein "kritischer Fehler", "anderer Fehler" oder "nicht in der Tabelle für die Fehlerservicestrategie gefunden". Das Werkzeug für die Fehlerklassifikation vergleicht die Fehler aus dem Fehlerlog 328 mit den in der Tabelle 330 für die Fehlerservicestrategie aufgelisteten Fehlern, um einen Indikatorwert für jeden Fehler zuzuordnen. Die Ausgangsfehlercodes mit dem Indikatorwert sind in 12 mittels des Bezugszeichens 332 angezeigt.
13 zeigt das Werkzeug 336 für die Datenpaket-Anomaliedetektion (DPAD). Dieses Werkzeug arbeitet mit Betriebsparameterdaten im Fehlerlog (auch als "Datenpaket"-Daten bezeichnet) innerhalb der Rückschauperiode (vgl. die Bezugszahl 338). Das Datenpaket wird gesammelt, wenn ein Fehler auftritt und liefert ein Maß für die betriebsmäßigen Bedingungen (Spannung, Temperatur etc.) von ausgewählten Lokomotivsystemen. Die DPAD Regeln sind in das Werkzeug 336 zur Feststellung der Datenpaketanomalie einprogrammiert, und das Werkzeug 336 zur Detektion der Datenpaketanomalie ist unter Benutzung der Eisenbahnnummer konfiguriert mittels der Parameter in der Konfigurationstabelle 30. Das "Datenpaket" besteht (in einer Ausführung) aus 16 Parametern, die beim Auftritt eines jeden Fehlers abgetastet werden. Das Werkzeug zur Feststellung der Datenpaketanomalie untersucht die Parameterwerte sowie den damit einhergehenden Fehler, um einen Reparaturvorschlag zu bestimmen. Der Ausgang von dem Werkzeug 336 zur Detektion der Datenpaketanomalie ist eine Liste von Reparaturcodes einschließlich aller Reparaturcodes, die von dem Regelvergleichsprozeß angegeben sind. Die ausgegebenen Reparaturcodes sind in allgemeiner Form in 13 mittels der Bezugszahl 344 angegeben.
Das Werkzeug 350 zur Feststellung bzw. Detektion von Anomalien ist in 14 dargestellt. Dieses Werkzeug analysiert die von dem laufenden Abspeicherfall (vgl. Bezugszeichen 353) empfangenen Parameter und vergleicht die Parameter mit Grenzen und Kriterien aus den Anomaliedefinitionen. Eine sog. Map- bzw. Abbildungsdatei 354 für die Maschinendiagnose liefert interne Anomaliecodes, die abgebildet werden zu Parametern in der Anomalie-Definitionstabelle. Wenn somit ein bestimmter Parameter zu einer Anomalie in der Tabelle korreliert, gibt das Werkzeug für die Anomaliedetektion den mit dieser Anomalie verbundenen internen Code aus. Es werden Konfigurationsdaten für das Werkzeug 350 zur Anomaliedetektion von einer in der Konfigurationstabelle 30 gespeicherten Initialisierungsdatei eingegeben. Diese Datei liefert die anfänglichen Konfigurationsdaten unter Einschluß der Versionsnummer des Werkzeugs für die Anomaliefeststellung, das anzuwenden ist, und zwar basierend auf der Eisenbahnnummer, von der die heruntergeladenen parametermäßigen Leistungsdaten gesammelt wurden. Die Anomalieindikatoren, die als ein Ausgang von dem Werkzeug 350 für die Anomaliedetektion geliefert werden, sind mittels der Bezugszahl 360 bezeichnet. Zusätzlich zu den Anomalieindikatoren 360 liefert das Werkzeug 350 zur Anomaliedetektion abgeleitete Parameter (zum Beispiel statistischer Art) als einen Ausgang. Diese sind in 14 durch die Bezugszahl 362 angegeben. Diese abgeleiteten Parameter werden aus den parametermäßigen Leistungsdaten in dem Abspeicherfall berechnet und werden in einer Datenbank oder Tabelle für eine Anwendung in Kurvendarstellungen oder anderen Hilfen für die Analysen abgespeichert.
15 stellt das Werkzeug 370 für den Anomalietrend dar. Wie das Werkzeug 350 für die Anomaliedetektion vergleicht auch dieses Werkzeug bestimmte Betriebsparameter von der Lokomotive mit definierten Werten in der Tabelle für die Anomaliedefinitionen, welche Tabelle allgemein mittels des Bezugszeichens 372 wiedergegeben ist. Die Information bezüglich der Konfiguration wird geliefert von der Konfigurationstabelle 30 für die Feststellung der spezifischen Version des Anomalietrendwerkzeugs 370, das, basierend auf der Lokomotivennummer mit den Daten betrieben werden soll. Es werden parametermäßige Leistungsdaten als Eingang auf das Werkzeug 370 für den Trend bzw. Verlauf eingegeben, welche Parameter von der Lokomotive hochgeladen werden (und dargestellt sind mittels der Bezugszahl 376). Es wird nur die Information von dem laufenden Abspeicherfall von dem Anoma lietrendwerkzeug 370 benutzt. Weiterhin eingegeben wird in das Anomalietrendwerkzeug 370 eine Statusdatei 378, welche statistische Daten (zum Beispiel die mittlere, die Medianwert-, die Standardabweichung) enthält, die von den Leistungsdaten aus der Vorgeschichte abgeleitet worden sind. Das Anomalietrendwerkzeug 370 analysiert die aktuellen Parameterdaten im Hinblick auf die Statistik aus der Vorgeschichte und vergleicht die Ergebnisse dieser Analyse mit in den Anomaliedefinitionen ausgeführten Grenzen und Kriterien, wie sie von der Definitionstabelle 372 vorgesehen werden. Das Anomalietrendwerkzeug 370 gibt die mit den Ergebnissen dieses Vergleichsprozesses (vgl. Bezugszahl 380) zusammenhängenden Anomaliefeststellungen als Ausgang aus und aktualisiert die statistischen Daten in der Statusdatei, wie das durch die Bezugszahl 382 angegeben ist. Die Statusdatei wird erneut initialisiert, wenn es innerhalb der Rückschauperiode irgendwelche geschlossenen oder vorgeschlagenen Fälle gibt. Weiterhin werden von dem Anomalietrendwerkzeug 370 abgeleitete Parameter 384 ausgegeben, die für die Erzeugung von Kurvendarstellungen, Diagrammen oder anderen Hilfsmitteln für die Analyse nützlich sind. Wie in Zusammenhang mit den anderen Werkzeugen, die angewendet werden, erörtert wurde, wird im Anschluß an die Anwendung des Anomalietrendwerkzeugs 370 ein Programm zur Feststellung von Fallwiederholungen in Gang gesetzt, (wie das in 8 mittels der Bezugszahl 118 dargestellt ist).
Um die begrenzten Mittel nur auf die Lösung von neuen, noch nicht gemeldeten Problemen zu konzentrieren, ist es nötig, die Erzeugung von neuen Problemfällen zu vermeiden, wenn bereits existierende Fälle dasselbe zuvor gemeldete Problem abdecken. Die Funktionen des Elements bzw. der Komponente zur Feststellung von Fallwiederholungen enthalten: die Fähigkeit zum Erkennen eines neuen Problemfalls basierend auf der Aufmachung der festgestellten Fehler, den Anomaliebedingungen sowie den vorgeschlagenen Reparaturen, wie sie von den automatisierten Analyse-Werkzeugen nach der vorliegenden Erfindung gemeldet werden; die Fähigkeit zum Erzeugen eines neuen Problemfalls, um Information über ein neues Problem zu speichern, die Fähigkeit zum Aufrechterhalten eines offenen Zeitrahmens, so daß verwandte Daten analysiert und, falls nötig, zu einem einzigen Problemfall kombiniert werden können; und die Fähigkeit zum Erkennen und Verbinden von zusätzlichen relevanten Daten mit bereits existierenden Fällen, anstatt einen neuen Fall zu erzeugen.
Zurückkehrend zu den 9A und 9B ist das Element zur Erkennung von Fallwiederholungen nach der vorliegenden Erfindung innerhalb der unterbrochenen Linien, bezeichnet mit dem Bezugszeichen 420, dargestellt. Das Ergebnis des Prozesses zur Feststellung von Fallwiederholungen ist die Erzeugung eines neuen Falls (vgl. die Schritte 224 und 238) oder das Hinzufügen der aktuellen Anomalie sowie Fehlerinformation zu einem existierenden Fall, wie bei dem Schritt 232 angegeben.
Der Prozeß zur Feststellung einer Fallwiederholung ist ebenfalls als Diagramm in 16 gezeigt. Die Bezugszahlen 422 und 424 bezeichnen Eingangswerte für den Fallwiederholungsprozeß 420. Der durch die Bezugszahl 422 repräsentierte Eingangswert stellt die Anzahl von Stunden dar, seitdem ein Problemfall erzeugt worden ist, während welcher Zeit alle Ausgänge von den Werkzeugprogrammen zu einem einzelnen Fall kombiniert werden sollten (vgl. Bezugszahl 422), und zwar statt mehrere Fälle zu erzeugen. Dieser Eingangswert wird vom Benutzer definiert und wird als "x" im Entscheidungsschritt 230 von 9A bezeichnet. Um den Prozeß zum Feststellen einer Fallwiederholung ablaufen zu lassen, werden aktuelle Reparaturen, Fehler sowie von den anderen Analyse-Werkzeugen gekennzeichnete Anomalien als Eingangswerte benutzt (vgl. Bezugszeichen 424 von 16). Wenn es keine Problemfälle innerhalb der gewählten Verknüpfungsperiode gibt, dann wird ein neuer Problemfall erzeugt. Wenn ein Problemfall innerhalb der Verknüpfungsperiode existiert, dann werden alle Reparaturvorschläge, die während dieser Periode gemacht werden (einschließlich der aktuellen vorgeschlagenen Reparaturen) zu einem Problemfall kombiniert. Wie oben erörtert, enthält jeder Fall die Fehler und Anomalien, die mit der Reparaturempfehlung zusammenhängen, und daher ist diese Information ebenfalls in dem Problemfall enthalten. Wenn die Bearbeitung außerhalb der Verknüpfungsperiode des Falles erfolgt, prüft der Prozeß 420 für die Feststellung einer Fallwiederholung alle offenen Problemfälle außerhalb der für den Fall geltenden Verknüpfungsperiode und fügt den neuen Problemfall als ein (logisches) Kind an einen existierenden Fall an, wenn die Reparaturen der beiden Problemfälle zueinander passen und wenn die Liste der Anomalien und Fehler von dem neuen Problemfall in dem existierenden Problemfall enthalten sind. Dieses Merkmal ist ebenfalls bei dem Schritt 232 und 242 in den 9A und 9B gezeigt. Wenn keine Überein stimmung besteht, dann wird ein neuer Problemfall erzeugt. Die Erzeugung eines neuen Falls mittels des Prozesses 420 zur Feststellung einer Fallwiederholung ist gezeigt als ein Ausgangsschritt 426.
Ein weiteres wichtiges Merkmal der vorliegenden Erfindung ist die erneute Analyse des erzeugten Problemfalls nach dem Abschluß einer vorgeschlagenen Reparatur. Dieser Prozeß ist in den 9A und 9B mittels des Bezugszeichens 440 gezeigt. Dieser Aspekt der vorliegenden Erfindung wird implementiert mittels der Anwendung eines Rückschauparameters, wie das zuvor hier erörtert wurde. Die Zielsetzung von diesem Merkmal ist es, Anomalien oder Fehler auszusondern, die in der Tat bereits sind durch kürzliche Reparaturaktionen oder Vorschläge adressiert worden sind. Im folgenden wird eine Zusammenfassung der mit dem erneuten Analyseprozeß 440 in Verbindung stehenden Schritte gegeben. Es werden dann Reparaturen nicht zu der Liste hinzugefügt, wenn alle der folgenden Bedingungen erfüllt sind: die Ergebnisse der Analyse zeigen an, daß eine anomale Bedingung vorliegt und/oder ein Reparaturcode benötigt wird (vgl. den Entscheidungsschritt 166 von 9A); die Lokomotive ist repariert worden oder es sind erst kürzlich Reparaturvorschläge gemacht worden (vgl. den Entscheidungsschritt 170 von 9A); die Codes für die anomalen Bedingungen und/oder Reparatur sind dieselben wie diejenigen, die vor dem Reparaturvorschlag oder dem Betrieb festgestellt wurden (vgl. den Entscheidungsschritt 180 von 9A); die Daten, die auf eine anomale Bedingung oder eine Reparatur hinwiesen, werden erneut analysiert, so daß eingangsseitig heruntergeladene Daten, die vor der Reparaturempfehlung oder dem Betrieb liegen, nicht in diese erneute Analyse eingeschlossen werden (vgl. den Schritt 182 von 9A); und die erneute Analyse zeigt an, daß keine anomale Bedingung vorliegt und keine Reparatur nötig ist (vgl. den Schritt 184 sowie den Entscheidungsschritt 186 von 9A).
17 stellt den Prozeß zum Identifizieren bestimmter Fehler als kritische Fehler sowie zum Anzeigen dieser Tatsache in Tabelle 330 für die Fehler-Servicestrategie dar. Weiterhin kommuniziert die bordseitige Überwachung Fehlerinformationen für eine Analyse gemäß dem hier angegebenen Analyseprozeß, und zwar basierend entweder auf einem bestimmten Zeitplan oder entsprechend dem Schweregrad des besonderen angetroffenen Fehlers. Insbesondere ist es erforderlich, einen Prozeß zum Bestimmen der sogenannten "kritischen Fehler" zu besitzen, wie nachfolgend definiert.
17 stellt ein beispielhaftes Flußdiagramm von einem Verfahren zum Feststellen von Fehlfunktionen dar, zum Beispiel von Fehlern und/oder Betriebsparametern, die auf nahe bevorstehende Fehler bei Eisenbahnlokomotiven hinweisen. Nach dem Start des Verfahrensablaufs im Schritt 500 werden in einem Schritt 502 alle für ein vorbestimmtes Zeitintervall (im Logbuch) aufgezeichnete Fehler aufgesucht, zum Beispiel in den letzten 12 Monaten oder in irgendeinem anderen ausgewählten Zeitintervall. Dieser Schritt wird durchgeführt, indem man zum Beispiel die beim Schritt 102 von 8 erzeugten Problemfälle überprüft. Bei einem Schritt 504 identifiziert das Verfahren Fehler, die relativ häufig auftreten. Der Schritt 506 erlaubt eine Feststellung der Anzahl von Lokomotiven, die am stärksten von den häufig auftretenden Fehlern beeinträchtigt werden. Zum Beispiel tritt, wie in der Tabelle 1 unten gezeigt, der Fehlercode 1000 in einem vorbestimmten Zeitintervall 1036 mal auf, der Fehlercode 1001 tritt 500 mal in demselben Zeitintervall auf, und der Fehlercode 1002 tritt 1269 mal in demselben Zeitintervall auf. Wie ferner in der Tabelle 1 gezeigt ist, gilt: obwohl der Fehlercode 1002 relativ zum Fehlercode 1001 häufiger auftritt, ist, da die Anzahl der von dem Fehlercode 1001 betroffenen Lokomotiven größer ist im Vergleich zur Anzahl der Lokomotiven, die vom Fehlercode 1002 betroffen sind, damit der relative Rangplatz des Fehlercodes 1001 hinsichtlich des betroffenen Prozentsatzes der Flotte für den Fehlercode 1001 höher als für den Fehlercode 1002. In einem Schritt 508 werden die Fehler in verschiedene Typen von Fehlern einklassifiziert, zum Beispiel in kritische, einschränkende, nicht-einschränkende Fehler, in Fehler von besonderem Interesse etc. Wie hier benutzt, ist ein kritischer Fehler ein Hinweis auf eine Fehlfunktion, die auf einen unmittelbar drohenden vollständigen Verlust der Lokomotivleistung, einen potentiellen Schaden für das fehlerhafte Untersystem und/oder die Lokomotive oder auf Sicherheitsprobleme hinweisen würde. Ein einschränkender Fehler ist ein Hinweis auf eine Fehlfunktion, welche die Lokomotive an einem Betrieb bei voller Kraft oder Leistung hindern würde, und zwar auf Grund von zum Beispiel mechanischen, elektrischen und/oder das Fahrvermögen betreffenden Fehlfunktionen. Ein Fehler von besonderem Interesse kann in Verbindung stehen mit einem individuellen Feldversuch oder mit einer für einen Eisenbahnbetreiber oder ein Projekt unternommenen Analyse und kann benutzt werden zum Überwachen der Tendenz bzw. des Verlaufs von vorbestimmten Betriebsparametern etc.
Tabelle 1
Der Schritt 512 läßt die Durchführung einer Expertenanalyse oder die Überprüfung durch Fachpersonal zu, zum Beispiel dem MDSC Personal und/oder von Ingenieurteams, die für den Service von irgendwelchen beeinträchtigten Untersystemen verantwortlich sind, zum Beispiel von Fahrmotoren, Untersystemen für die Kraftstoffversorgung etc.
Wie oben vorgeschlagen, läßt der Schritt 514 eine Verarbeitung von Fehlern von speziellem Interesse, von Fehlertendenzen, von kritischen Fehlern etc. zu, wenn das erwünscht ist. Insbesondere kann der Analyse-Planer 15 (vgl. 2) zur Stapelverarbeitung von irgendeiner Gruppe von Fehlerdaten gemäß den Maßnahmen dieser Erfindung benutzt werden. Der Schritt 516 erlaubt in einer geeigneten Datenbank ein Speichern eines jeden Fehlers, der bei einer entsprechenden Lokomotive die Anforderung eines Heimrufs auslösen würde. In einer Ausführung werden diese Fehler als die Heimruf- oder kritischen Fehler klassifiziert. Wie im Schritt 518 gezeigt, handelt es sich bei dem Vorgang um einen iterativen Prozeß, der wiederholt werden kann, um eine aktualisierte Datenbank von allen Heimruffehlern aufrechtzuerhalten. Die Aktualisierung kann zu vorgeschriebenen Zeitintervallen durchgeführt werden, oder sie kann durchgeführt werden aufgrund von speziellen Vorfällen, zum Beispiel der Inbetriebnahme von neuen Modellen von Lokomotiven, von Lokomotiv-Aufrüstungen etc.

Claims

Verfahren zum Planen der Ausführung von einem oder mehreren Analyse-Werkzeugen (110, 112, 114, 116, 128, 130), die an Leistungsdaten von mehreren mobilen Gütern (2) arbeiten, um das Erfordernis für eine Abhilfe an einem oder mehreren mobilen Gütern (2) abzuschätzen, enthaltend: a) Empfangen der Leistungsdaten (124), b) Speichern der Leistungsdaten, c) Wählen der höchsten Priorität von unanalysierten Leistungsdaten (61), d) Festlegen einer Grenze für die verfügbare Anzahl von Ausführungen, die während eines vorbestimmten Zeitintervalls für jedes von dem einen oder mehreren Analyse-Werkzeugen (62) ausgeführt werden sollen, e) Bereitstellen, unter Verwendung eines Analyse-Planers (15), der gewählten unanalysierten Leistungsdaten für das eine oder die mehreren Analyse-Werkzeuge, wenn die Ausführungsgrenze für dieses Werkzeug nicht erreicht worden ist (63), und f) Generieren eines speziellen Vorschlags für das mobile Gut auf der Basis der Ergebnisse, die von dem einen oder mehreren Analyse-Werkzeugen (306, 318, 332, 344, 366) abgeleitet werden.
Verfahren nach Anspruch 1, wobei der Schritt c) enthält: c1) Ausbilden von mehreren Leistungsdatensätzen (21), wobei jeder Satz Leistungsdaten enthält, die mit einem Betriebsereignis an Bord des mobilen Gutes in Beziehung stehen, c2) Zuordnen einer Prioritäts-Reihenfolge zu jedem Leistungsdatensatz und c3) Auswählen (44) des Leistungsdatensatzes mit der höchsten Priorität.
Verfahren nach Anspruch 1, wobei der Schritt c) enthält: c1) Einteilen der Leistungsdaten in Daten mit hoher Priorität und in Daten mit normaler Priorität und c2) Auswählen (61) der Leistungsdaten mit höchster Priorität aus jeweils den Daten mit hoher Priorität und den Daten mit normaler Priorität.
Verfahren nach Anspruch 1, ferner enthaltend: f) Festlegen (182) einer Rückschauperiode, wobei die Leistungsdaten die Leistungsdaten des mobilen Gutes während der Rückschauperiode enthalten, g) Ermitteln ob der gegenwärtige spezielle Vorschlag für das mobile Gut im wesentlichen ähnlich mit einem oder mehreren vorherigen Vorschlägen ist, h) wenn der gegenwärtige spezielle Vorschlag für das mobile Gut im wesentlichen ähnlich mit wenigstens einem vorherigen Vorschlag innerhalb der Rückschauperiode ist, Ändern der Rückschauperiode derart, dass die geänderte Rückschauperiode nach der Implementation des vorherigen Vorschlags beginnt (182), und i) Wählen (184) unanalysierter Leistungsdaten während der geänderten Rückschauperiode zur Analyse.
Hergestellter Gegenstand enthaltend: ein Computerprogrammprodukt enthaltend ein computerverwendbares Medium, das einen computerlesbaren Code enthält zum Planen der Ausführung von einem oder mehreren Analyse-Werkzeugen, die Leistungsdaten von mehreren mobilen Gütern bearbeiten, um das Erfordernis zur Abhilfe von einem oder mehreren mobilen Gütern abzuschätzen, wobei der computerlesbare Code in dem hergestellten Gegenstand enthält: ein computerlesbares Programmcodemodul zum Speichern der Leistungsdaten, ein computerlesbares Programmcodemodul zum Wählen der unanalysierten Daten mit höchster Priorität (61), ein computerlesbares Programmcodemodul zum Festlegen einer Grenze für die verfügbare Anzahl von Ausführungen, die während eines vorbestimmten Zeitintervalls für jedes von dem einen oder mehreren Analyse-Werkzeugen (62) ausgeführt werden sollen, ein computerlesbares Programmcodemodul zum Bereitstellen, unter Verwendung eines Analyse-Planers (15), der gewählten unanalysierten Leistungsdaten für das eine oder die mehreren Analyse-Werkzeuge, wenn die Ausführungsgrenze für dieses Werkzeug nicht erreicht worden ist (63), und ein computerlesbares Programmcodemodul zum Generieren eines speziellen Vorschlags für das mobile Gut auf der Basis der Ergebnisse, die von dem einen oder mehreren Analyse-Werkzeugen (306, 318, 332, 344, 366) abgeleitet sind.
Einrichtung zum Planen der Ausführung von einem oder mehreren Analyse-Werkzeugen, die an Leistungsdaten von mehreren mobilen Gütern arbeiten, um das Erfordernis für eine Abhilfe an einem oder mehreren mobilen Gütern abzuschätzen, wobei das Analyse-Werkzeug eine vorbestimmte Grenze für die verfügbare Anzahl von Ausführungen enthält, die während eines vorbestimmten Zeitintervalls ausgeführt werden sollen, wobei die Einrichtung enthält: eine Empfangsvorrichtung (20) zum Empfangen der Leistungsdaten, eine Speichervorrichtung (21) zum Speichern der Leistungsdaten, einen Analyse-Planer (15) zum Wählen von unanalysierten Leistungsdaten höchster Priorität aus der Speichervorrichtung (21) und zum Bereitstellen der gewählten Leistungsdaten als ein Eingang zu einem oder mehreren Analyse-Werkzeugen (110, 112, 114, 116, 128, 130), wenn die Anzahl von Ausführungen, die während eines vorbestimmten Zeitintervalls für eine Ausführung zur Verfügung stehen, für dieses Werkzeug nicht erreicht worden ist, und ein Vorschlags-Erzeugungsmodul (186) zum Erzeugen eines speziellen Vorschlags für das mobile Gut auf der Basis der Ergebnisse, die von dem einen oder mehreren Analyse-Werkzeugen abgeleitet sind.
Einrichtung nach Anspruch 6, wobei der Analyse-Planer (15) die Leistungsdaten in Daten mit hoher Priorität und in Daten mit normaler Priorität teilt und einen Selektor (44) aufweist zum Auswählen der Leistungsdaten mit höchster Priorität aus jeweils den Daten mit hoher Priorität und den Daten mit normaler Priorität.
Einrichtung nach Anspruch 6, enthaltend eine Rückschauperiode, wobei die gewählten Leistungsdaten den Betrieb des mobilen Gutes während der Rückschauperiode beschreiben, einen Komparator zum Ermitteln ob der gegenwärtige spezielle Vorschlag für das mobile Gut im wesentlichen ähnlich mit einem oder mehreren vorherigen Vorschlägen ist (244), und, wenn der gegenwärtige Vorschlag im wesentlichen ähnlich zu wenigstens einem vorherigen Vorschlag ist (244), Ändern der Rückschauperiode derart, dass die geänderte Rückschauperiode nach der Implementierung des vorhe rigen Vorschlags beginnt, wobei die gewählten Leistungsdaten die Leistung des mobilen Gutes während der geänderten Rückschau beschreibt.
Einrichtung nach Anspruch 7, ferner enthaltend: einen ersten Begrenzer zum Festlegen einer Grenze für die Anzahl von Ausführungen mit hoher Priorität für jedes Analyse-Werkzeug, die zur Ausführung während eines vorbestimmten Zeitintervalls zur Verfügung stehen, und einen zweiten Begrenzer zum Festlegen einer Grenze für die Anzahl von Ausführungen mit normaler Priorität für jedes Analyse-Werkzeug, die zur Ausführung während eines vorbestimmten Zeitintervalls für jedes Analyse-Werkzeug zur Verfügung stehen.
Verfahren zum Identifizieren betrieblich signifikanter Fehler an Bord eines mobilen Gutes, wobei das Verfahren enthält: a) Empfangen von Leistungsdaten für jedes mobile Gut (20), b) Bereitstellen, unter Verwendung eines Analyse-Planers (15), der Leistungsdaten für ein oder mehrere Analyse-Werkzeuge (110, 112, 114, 116, 128, 130), c) Ermitteln des Bestehens eines Fehlers an Bord des mobilen Gutes (502), d) Erzeugen eines speziellen Vorschlags für das mobile Gut durch das eine oder die mehreren Analyse-Werkzeuge, e) Vergleichen des speziellen Vorschlags für das mobile Gut mit einer Liste von Vorschlägen, die einen betrieblich signifikanten Fehler anzeigen, und f) Ermitteln, dass der Fehler ein betrieblich signifikanten Fehler ist, auf der Basis der Ergebnisse des Schrittes e).