-
Die
Erfindung betrifft ein Verfahren zur Systemdiagnose in technischen
Systemen mit mehreren Systemkomponenten
-
Derartige
komplexe Systeme bestehen oft aus mehreren rechentechnischen Systemkomponenten,
d. h. Verarbeitungseinheiten, die miteinander durch Austausch von
Daten in Wechselwirkung stehen. Die jeweiligen Verarbeitungseinheiten
besitzen einen mehr oder weniger großen Umfang an eigenständig ablaufenden
Funktionen sowie eine Anzahl von Schnittstellen zur Umwelt. Über Schnittstellen werden
zwei oder mehr Verarbeitungseinheiten miteinander gekoppelt und
dadurch in ihrer Funktion voneinander entkoppelt. In derart aufgebauten
Architekturen können
neben Prozessoren beispielsweise auch Sensoren und Aktoren eingebunden
sein.
-
Bei
verteilten Echtzeitsystemen werden meist sehr kurze Reaktionszeiten
auf Zustandsänderungen
im System auch über
die Grenzen der Schnittstellen verschiedener Verarbeitungseinheiten benötigt. In
diesen Systemen ist neben einem ausreichend schnellen Datenaustausch
meistens die Kapazität
der Datenverarbeitung in der Verarbeitungseinheit eine knappe Ressource.
Durch geeignete Dekomposition der Systemanforderungen auf Verarbeitungseinheiten – funktionale
Kohärenz – und Minimierung
der Anforderungen an die Datenübertragung – Kapselung – werden
Performanceprobleme minimiert.
-
Bei
einer Reihe von komplexen Systemen liegt die Verteilung der Verarbeitungseinheiten
darin begründet,
dass es sich um mobile Einheiten handelt, die untereinander und/oder
mit ortsfesten Systemkomponenten kommunizieren, meistens unter Verwendung
von Funktechnik. Die Funkanbindung ist eine systembestimmende Schnittstelle,
die oft nicht nur dem Austausch von Prozessdaten dient, sondern zugleich
auch der Systemdiagnose.
-
Weiterhin
ist die räumliche
Anordnung von Systemzugängen
ein wichtiger Grund für
deren Verteilung, wie beispielsweise bei Kommunikationsnetzen.
-
Sicherheitsrelevante
Systeme, beispielsweise Eisenbahnsicherungssysteme, besitzen oft
mehrere interagierende Verarbeitungseinheiten unterschiedlicher
Sicherheitsanforderungsstufen – Safety Integrity
Level – SIL.
Da der Entwicklungsaufwand für sicherheitsrelevante
Anforderungen mit zunehmendem SIL ansteigt, besteht für diese
Systeme das wirtschaftliche Interesse, Funktionen unterschiedlicher Sicherheitsanforderungsstufen
in separaten Verarbeitungseinheiten anzuordnen.
-
Die
Kopplung der Verarbeitungseinheiten verteilter Systeme kann synchron
oder asynchron erfolgen. Bei synchroner Kopplung erfolgt der Datenaustausch
zyklisch durch Abgleich interner Prozesszustände. Bei asynchroner Kopplung
werden Daten ereignisorientiert ausgetauscht, wodurch das Datenaufkommen
geringer ist. Asynchrone Schnittstellen, über die ereignisorientiert
Daten ausgetauscht werden, können
im Gesamtsystem dann zu Problemen führen, wenn eine Verarbeitungseinheit
ausgefallen ist. Da in diesem Fall keine Ereignisse mehr beim Schnittstellenpartner
eintreffen, müssen
spezielle Mechanismen für
die Ausfalloffenbarung eingesetzt werden. Dieses Problem wird bei
synchronen Schnittstellen implizit gelöst, da ein Ausfall automatisch
durch Ausbleiben der Daten offenbart wird.
-
Verteilte
komplexe Systeme benötigen
systeminterne Diagnosefunktionen, um wirtschaftlich wartbar zu sein.
An die Systemdiagnose werden erheblich höhere Anforderungen gestellt,
als beispielsweise nur die Information des Nutzers über ausgefallene
Komponenten. Durch einen steigenden Anteil von Software und immer
komplexere Strukturen auf der Basis zunehmend leistungsfähiger Hardware
erhält
die Systemdiagnose einen neuen Stellenwert. Systementwickler benötigen interne
Prozesszustände
und Prozesshistorie für
die Analyse und Beseitigung komplexer Fehlerbilder. Kunden benötigen Informationen über Ausfälle und
den Betriebszustand der Anlage. Dispatching-Dienste benötigen für die Betriebsüberwachung
gefilterte und aufbereitete Daten von Systemschnittstellen, anhand
derer Leistungsparameter und Auslastung der Anlage protokolliert
und gesteuert werden können.
Für Wartungs- und
Inbetriebsetzungsdienste sind Informationen zu Wartungsmaßnahmen,
Ersatzteilen und Prüfung
der Anlage notwendig.
-
Neben
den inhaltlich verschiedenen Diagnoseinformationen spielen auch
die Art der Übermittlung
und die geeignete Aufbereitung der Diagnosedaten eine wesentliche
Rolle. Oft besteht die Anforderung an die Verarbeitungseinheiten,
die Diagnosedaten in einem Netzwerk an eine zentrale Stelle oder an
mehrere spezialisierte Stellen zu übermitteln, so dass aufwendige
manuelle Datenlogistik vermieden wird. In der Regel sollen dafür die bestehenden Übertragungseinrichtungen
mitbenutzt werden. Meistens müssen
die Daten außerdem
entsprechend gefiltert, verdichtet und aufbereitet werden, um erstens
das Datenaufkommen im Übertragungsnetz
zu begrenzen bzw. mittels Prioritätensteuerung zu regulieren und
zweitens eine zeitsparende Auswertung zu ermöglichen.
-
Die
hohen Anforderungen an die Diagnosefähigkeit in verteilten komplexen
Systemen müssen bereits
bei den Architekturent scheidungen berücksichtigt werden. Ein nachträgliches
Einbauen von Diagnoseeinrichtungen in ein bestehendes System ist technisch
und wirtschaftlich nicht effektiv.
-
Komplexe
softwarebasierte Systeme sind modular strukturiert. Die Diagnose
ist mindestens bezüglich
der Datengewinnung integraler Bestandteil des Systems. Software-Module
erzeugen bei festgelegten Ereignissen oder nach bestimmten Regimen, beispielsweise
zeitbasiert, Diagnosedaten, um neben ihrer Systemfunktion zustandsbezogene
Diagnoseinformationen verfügbar
zu machen. Oft kann der Umfang der Diagnosemeldungen durch Projektierung
oder Konfiguration eingestellt werden, um beispielsweise in Phasen
der Systemstabilisierung oder Fehlersuche mehr oder detailliertere
Diagnosedaten erhalten zu können
als im Regelbetrieb eines Systems. Vielfach werden die auf modularer
Ebene gewonnenen Diagnosedaten anschließend zu einer speziell für Diagnosezwecke
konzipierten Diagnoseverarbeitungseinheit übertragen und dort weiterverarbeitet
und gespeichert. Es können
eine oder mehrere Diagnoseverarbeitungseinheiten im System angeordnet
sein. Diagnoseverarbeitungseinheiten können neben den Schnittstellen
zu den Softwaremodulen weitere Schnittstellen zu externen Geräten, z.
B. Sensoren, oder zum Menschen – MMI – aufweisen. In
der Regel besitzen sie auch Speichermöglichkeiten für Diagnosedaten.
Für die
Auswertung und Interpretation der Daten werden oft weitere separate
Vorrichtungen und Programme benutzt. Eine übliche Methode ist der rechnergestützte Zugriff
auf die Daten von Diagnoseverarbeitungseinheiten, um die gesammelten
Diagnosedaten beispielsweise abzurufen, auszuwerten und zu archivieren.
-
Typisch
für komplexe
verteilte Systeme ist eine hierarchische Struktur, bei der Diagnose-Primär-Informationen
dezentral auf Ebene von Softwaremodulen oder Hardwarekomponenten
gewonnen werden und zu speziellen Diagnoseverarbeitungseinheiten übertragen
und weiterverarbeitet werden. Art und Umfang der Diagnosedatenerzeugung ist
in Softwaremodulen entweder fest codiert oder über Parameter einstellbar.
-
Ein
häufiges
Problem bei der Systemdiagnose besonders im Zusammenhang mit komplexen Softwarefehlern
liegt im Umfang der Diagnosedaten. Werden zu wenige Diagnosedaten
protokolliert, reichen die verfügbaren
Daten gegebenenfalls nicht aus, um auftretende Fehler detailliert
analysieren oder reproduzieren zu können. Andererseits führt die massive
Erzeugung und Speicherung von Diagnosedaten, z. B. Tracing, oft
zu erheblichen Datenmengen, die einen hohen Aufwand für Speicherung,
Logistik, und Auswertung erfordern und damit die Systemkosten erhöhen. Weiterhin
kann die massive Erhöhung
des Diagnosedatenaufkommens zu Performanceproblemen und einem veränderten
Zeitverhalten des Systems führen,
was die Systemnutzung unerwünscht
beeinflusst.
-
Der
Erfindung liegt die Aufgabe zugrunde, diese Nachteile zu beseitigen
und ein Verfahren der gattungsgemäßen Art anzugeben, bei dem
Art und Umfang der zu übertragenden
Diagnosedaten optimiert sind, wobei das Datenvolumen so weit wie möglich reduziert
werden soll.
-
Erfindungsgemäß wird die
Aufgabe dadurch gelöst,
dass eine zentrale Systemdiagnose, d. h. ein Diagnoseorakel, vorgesehen
ist, wobei das Diagnoseorakel Art und Umfang der von den Systemkomponenten
an das Diagnoseorakel zu übertragenden
Diagnosedaten in Abhängigkeit
von bereits übergebenen
Diagnosedaten und im Diagnoseorakel hinterlegten Regeln steuert.
-
Mit
dem erfindungsgemäßen Verfahren
wird eine Diagnosefunktionalität
im System eingeführt, welche
eine automatische adap tive Regelung des Diagnosedatenaufkommens
in Abhängigkeit
von festgelegten Regeln, insbesondere bezüglich Ereignissen oder Schwellwerten,
erlaubt. Die Diagnosefunktionalität beinhaltet Regeln für die Interpretation
der aktuellen Diagnosedaten und steuert anhand dieser Regeln Art
und Umfang der zukünftig
zu generierenden Diagnosedaten.
-
Weiterhin übernimmt
die Diagnosefunktionalität
neben der adaptiven Steuerung des Diagnosedatenaufkommens bei Bedarf
die Steuerung der Weiterverarbeitung, Speicherung, Übertragung
und Ausgabe von Diagnosemeldungen. Sie bildet damit ein so genanntes
Diagnoseorakel.
-
Das
erfindungsgemäße Verfahren
deckt unterschiedliche Diagnoseanforderungen mit einem einheitlichen
Konzept ab – Entwicklerdiagnose,
Kundendiagnose, Systemwartung. Die Systementwicklung wird durch
die konsequente Trennung von System- und Diagnosefunktionen besser
modularisiert. Das Design der Systemkomponenten vereinfacht sich.
Durch das verfahrensbedingte Komponentendesign verbessert sich die
Testbarkeit des Systems. Die Trennung von Diagnose und Systemfunktion
vermeidet unerwünschte
Rückwirkungen
auf das System bei erhöhten
Diagnoseaktivitäten.
-
Die
Entwicklung von Diagnosefunktion – Diagnoseorakel – und Systemfunktion
kann getrennt erfolgen, wenn die Schnittstelle zwischen System und Diagnoseorakel
spezifiziert ist
-
Das
Diagnoseorakel kann als Testwerkzeug verwendet werden. Die Verwendung
ist sowohl während
der Systementwicklung, als auch während des Betriebes des Systems
möglich.
-
Die
Diagnosefunktionen können
in separater Hardware ablaufen, wobei die Diagnosefähigkeit
des Systems auch bei ausgefallenen Systemkomponenten erhalten bleibt.
-
Durch
das adaptive Verfahren werden automatisch Daten in ausreichender
Menge und Informationstiefe gewonnen, die für eine spätere Analyse der Systemfehler
notwendig sind. Dabei sorgt das Verfahren dafür, dass der Umfang der entstehenden
Diagnosedaten auf ein Minimum reduziert wird. Mit dem Wegfall überflüssiger nicht
benötigter
Diagnosedaten werden Speicher- und Logistikaufwand optimiert. In
Echtzeitsystemen können
Performanceprobleme vermieden werden, indem Diagnosefunktionen ausgelagert
werden und die Systemlast auch bei hohem Tracedatenaufkommen deterministisch bleibt.
-
Die
zentrale Diagnosefunktion des Diagnoseorakels ermöglicht die
einfache Ankopplung an zentrale Dienste, z. B. Datenspeicher, und
Systemschnittstellen, wie beispielsweise eine zentrale Wartungsschnittstelle.
-
Wegen
der variablen Definition von Daten und Verarbeitungsvorschriften
im Diagnoseorakel und zu den Schnittstellen von Systemkomponenten besitzt
das adaptive Diagnoseverfahren eine hohe funktionale Flexibilität und Skalierbarkeit.
Damit ist beispielsweise auch eine einfache Erweiterungsfähigkeit
bestehender Diagnoseorakel durch Veränderung bestehender Analysealgorithmen
ohne Rückwirkung
auf das System möglich.
-
Vorteilhafte
Weiterbildungen sind in den Unteransprüchen gekennzeichnet und werden
nachfolgend anhand figürlicher
Darstellungen näher
erläutert.
Es zeigen:
-
1 Systemkomponenten
im Zusammenwirken mit einem Diagnoseorakel und
-
2 den
Aufbau eines Diagnoseorakels.
-
Das
Prinzip des Diagnoseorakels ist in 1 gezeigt.
-
Über Schnittstellen
zu Systemkomponenten werden Diagnosedaten an ein Diagnoseorakel übergeben.
Die Initiative für
die Übergabe
von Diagnosedaten an das Diagnoseorakel kann entweder vom Diagnoseorakel
ausgehen – Holepflicht – oder von
den Systemkomponenten – Bringepflicht.
Im Diagnoseorakel werden die eintreffenden Daten anhand von hinterlegten
Regeln bewertet. Die Regeln erlauben eine Beurteilung des Systemzustandes.
Für die
Beurteilung des Systemzustandes können bei Bedarf mehrere Diagnosedaten
unterschiedlicher Systemkomponenten verknüpft und ausgewertet werden. Zusätzliche
Verarbeitungsschritte wie beispielsweise Filterung und Extrapolation
sind möglich,
um im Diagnoseorakel eine Prognose über mögliche Fehlerzustände des
Systems treffen zu können.
-
Lassen
sich anhand der eintreffenden Daten Indizien für einen Fehlerzustand im System
ableiten, werden durch das Diagnoseorakel Steueranweisungen an die
Komponenten des Systems ausgegeben, die zu einem erhöhten Diagnosedatenfluss
von den Systemkomponenten zum Diagnoseorakel führen. Es erfolgt also durch
das Diagnoseorakel eine direkte Beeinflussung des Ausgabeverhaltens
von Systemkomponenten bezüglich
der Systemdiagnose. Dabei werden durch das Diagnoseorakel gezielt
diejenigen Systemkomponenten in erhöhten Diagnoseausgabemodus geschaltet,
in denen Indizien für
fehlerhafte Systemzustände
ermittelt wurden oder die für
die Fehleranalyse relevante Informationen liefern können. Diese
Komponenten produzieren daraufhin einen entsprechend umfangreicheren
Daten-Output und versorgen das Diagnoseorakel mit detaillierten Daten,
die eine spätere
genaue Analyse des fehlerhaften Systemverhaltens ermöglichen.
-
Die
vom Diagnoseorakel auf Basis von Diagnoseregeln und Diagnosedaten
gesteuerten Aktivitäten
im Falle von Fehlerereignissen können
neben der Aktivierung von zusätzlichem
Diagnose-Output der Systemkomponenten weitere Maßnahmen umfassen. Beispielsweise
wird die Langzeitspeicherung der Daten, die mit dem Fehlerereignis
in Zusammenhang stehen aktiviert, oder es werden Meldungen an übergeordnete
Einrichtungen ausgegeben.
-
Das
Diagnoseorakel ist bei Eintritt von Diagnose- oder Fehlerereignissen
dafür zuständig, dass geeignete
Diagnosedaten in ausreichender Menge und Informationstiefe gewonnen,
aufbereitet und abgelegt werden. Daneben sorgt es für die Weitergabe von
Meldungen und Daten an Systemschnittstellen, wie beispielsweise
die Systemwartung, um über
bestimmte Ereignisse im System zu informieren. In diesem Zusammenhang
können
vom Diagnoseorakel auch Funktionen zur Informationsbegrenzung und -unterdrückung bereitgestellt
werden, die dafür
sorgen, dass parallele und wiederholte Meldungen zum selben Ereignis – Informationsschauer – unterbleiben.
-
Die
Treffsicherheit der durch das Diagnoseorakel erkannten Fehlerereignisse
hängt von
der Komplexität
des Systems und der im Diagnoseorakel hinterlegten Regeln ab. Entsprechend
der Genauigkeit und Komplexität
der hinterlegten Regeln wird das Diagnoseorakel mehr oder weniger
exakte Analysen und dazu passende Aktionen durchführen können. Beispielsweise
hängt von
der Einstellung eines Schwellwertes ab, wie schnell das Diagnoseorakel auf
Daten, die ein Abweichen vom Normalbetrieb bedeuten können, reagiert.
-
In
einem komplexen System können
oft nicht alle Fehlermöglichkeiten
vorausschauend analysiert und Kriterien für ihren Eintritt abgeleitet
werden. Aus diesem Grund kann es Fehler ereignisse im System geben,
die keine Reaktion im Diagnoseorakel bewirken. Andererseits kann
es dazu kommen, dass vom Diagnoseorakel Daten als fehlerhaft interpretiert
werden, denen kein fehlerhaftes Systemverhalten zugrunde liegt und
die im Diagnoseorakel dennoch entsprechende Aktionen und Steuerflüsse auslösen. Die korrekte
Reaktion des Diagnoseorakels hängt
somit von der Genauigkeit der auf den hinterlegten Regeln basierenden
Datenanalyse ab und wird durch den Entwurf des Diagnoseorakels und
seiner Schnittstellen zu den Systemkomponenten bestimmt.
-
Das
erfindungsgemäße Verfahren
bedingt das Zusammenwirken von Systemkomponenten und Diagnoseorakel über spezielle
Schnittstellen. Die Schnittstelle zwischen Diagnoseorakel und System ist
spezifisch für
jede Systemkomponente. Über
die Schnittstelle fließen
Diagnosedaten von der Systemkomponente in Richtung Diagnoseorakel.
Art und Umfang der übertragenen
Diagnosedaten hängen von
der Systemkomponente und dem geforderten Ausgabeumfang – Tracelevel – ab. Die
Diagnosedaten werden im Diagnoseorakel benutzt, um auf das Verhalten
und mögliche
Fehler im System zu schlussfolgern. Weiterhin fließen über die
Schnittstelle Steueranweisungen aus dem Diagnoseorakel in Richtung
Systemkomponente, womit die Systemkomponente bezüglich ihrer Datenausgabe angewiesen
wird, mehr oder weniger Diagnosedaten an das Diagnoseorakel zu liefern – Steuerung
Tracelevel. Dabei ist bereits bei der Schnittstellendefinition festgelegt,
um welche Art von Diagnosedaten es sich handelt und in welchen Schritten
die Ausgabe erhöht oder
vermindert werden kann.
-
Mit
der Einführung
der Schnittstellen zwischen Systemkomponenten und dem Diagnoseorakel
sind qualitativ neue Designanforderungen an die Systemkomponenten
verbunden. Die Funktionen der Diagnose, die den Zustand des Systems
analysieren und bewerten, werden nicht mehr in den Systemkomponenten
implementiert, sondern im Diagnoseorakel. Die Systemkomponenten
liefern Diagnosedaten, die aus ihrer spezifischen Funktion im System
resultieren, an das Diagnoseorakel. Der Umfang der an das Diagnoseorakel
gelieferten Daten wird durch das Diagnoseorakel entsprechend den
Ergebnissen der Zustandsanalyse reguliert. Bei den von den Systemkomponenten
an das Diagnoseorakel gelieferten Diagnosedaten handelt es sich
um Rohdaten, die in den Systemkomponenten keiner Analyse zwecks
Diagnose bedürfen.
Dadurch kann der Aufbau der Systemkomponenten einfacher erfolgen.
-
Die
Systemkomponenten müssen
in der Lage sein, die Datenausgabe an das Diagnoseorakel entsprechend
des geforderten Tracelevels zu generieren. Die Performance einer
Systemkomponente kann unter der Randbedingung der maximalen Datenausgabe
an das Diagnoseorakel modelliert und geprüft werden. Sofern eine Komponente
in diesem Fall anforderungsgemäß arbeitet
und das Diagnoseorakel über
separate Systemressourcen verfügt, kann
davon ausgegangen werden, dass durch die Systemdiagnose keine unzulässige Rückwirkung
auf die Systemperformance erfolgt.
-
Beim
Systemdesign werden die Diagnosefunktionen für jede Systemkomponente definiert.
Die Definition erfolgt über
Daten und Vorschriften, die eine Systemkomponente für das Diagnoseorakel
exportiert. Die Vorschriften beinhalten Regeln für die Verarbeitung und Interpretation
der von der Systemkomponente gelieferten Diagnosedaten. Sie definieren
weiterhin Diagnoseereignisse, die beim Auftreten bestimmter Diagnosedaten
oder Analyseergebnisse entstehen. Außerdem enthalten die Vorschriften
Anweisungen für
Aktivitäten
des Diagnoseorakels, die nach dem Eintritt von Diagnoseereignissen
durchzuführen
sind. Zu diesen Aktivitäten
kann beispielsweise die Umschal tung des Tracelevels für verschiedene
Systemkomponenten oder die Ausgabe von Daten an externe Schnittstellen
gehören.
-
Von
den im Rahmen des Designs der Systemkomponenten festgelegten Diagnosedaten
und Vorschriften für
die Systemdiagnose hängt
die Treffsicherheit und Präzision
der Funktion des Diagnoseorakels entscheidend ab. Das bedeutet,
dass beim Design der Systemkomponenten mit der Definition der Schnittstelle
zum Diagnoseorakel auch dessen Funktion und Qualität bestimmt
werden.
-
Im
Rahmen des Komponentendesigns müssen
folgende Festlegungen für
die komponentenspezifischen Schnittstellen zum Diagnoseorakel getroffen
werden:
- 1. vorgesehene Tracelevel und Kriterien
für deren Wechsel
- 2. Spezifikation der Diagnosedaten für die Ausgabe an das Diagnoseorakel,
abhängig
vom Tracelevel
- 3. Spezifikation der Steuerflüsse für die Umschaltung der Tracelevel
- 4. Vorschriften für
die Verarbeitung der an das Diagnoseorakel übertragenen Diagnosedaten,
z. B. Filtern, Speichern
- 5. Diagnoseereignisse und Kriterien für deren Auftreten, z. B. Schwellwerte
- 6. durchzuführende
Aktivitäten
infolge von Diagnoseereignissen.
-
Vom
Diagnoseorakel können
bei Bedarf die Diagnosedaten mehrerer Systemkomponenten entgegengenommen
und weiterverarbeitet werden. Damit bietet sich auch die Möglichkeit,
die Diagnosedaten verschiedener Systemkomponenten miteinander zu
verknüpfen,
um daraus Schlussfolgerungen über Fehlerzustände im System
zu ziehen. Dadurch werden Prognosen des Diagnoseorakels auf wesentlich breiterer
Grundlage möglich
sowie die Beurteilung übergeordneter
und komplexer Systemzustände.
-
Ein
Beispiel für
die Realisierung eines Diagnoseorakels zeigt 2. In einem
System gibt es eine Anzahl verschiedener Diagnose-Interfaces, die Informationen
aus dem System bereitstellen. Um die Diagnosedaten in einer für das Diagnoseorakel
geeigneten Form zu erhalten, können
interfacespezifische Adapter eingesetzt werden. Die Interfaceadapter
können
auch die Umschaltung des Tracelevels in den Systemkomponenten übernehmen.
Die von den Diagnose-Interfaces gelieferten primären Diagnoseinformationen werden
durch das Diagnoseorakel anhand von hinterlegten Bewertungsalgorithmen
verarbeitet. Dazu kann das Diagnoseorakel eine beliebige Anzahl
von Plausibilitätsprüfungen durchführen – als Plausibilitäts-Orakel
dargestellt. Die Plausibilitäts-Orakel
können
alle bereitgestellten primären
Diagnosedaten in beliebiger Art und Weise verknüpfen und verarbeiten, um auf
den Diagnosezustand des Systems zu schlussfolgern. Werden anhand
von Indizien Fehlerzustände
neu oder als nicht mehr bestehend erkannt, erfolgt durch die Plausibilitäts-Orakel die
Ausgabe von Steuerbefehlen an einen oder mehrere der Interface-Adapter,
um die Tracelevel der zugeordneten Systemkomponenten zu erhöhen oder zu
erniedrigen. Weiterhin werden von den Plausibilitäts-Orakeln
Anweisungen an einen zentralen Massendaten-Manager ausgegeben, um
dessen Protokollierungsfunktion ein- oder auszuschalten. Der Massendaten-Manager
speichert selektiv diejenigen primären Diagnosedaten, die für den aktuellen
Fehlerzustand relevant sind. Zusätzlich
können
weitere Daten der Plausibilitäts-Orakel
als Kontextinformation für
eine spätere
Auswer tung abgespeichert werden. Über eingetretene Diagnoseereignisse
können sowohl
durch die Plausibilitäts-Orakel,
als auch durch den Massendaten-Manager Informationen an übergeordnete
Subsysteme oder an externe Schnittstellen ausgegeben werden.
-
Die
Wirkungsweise des erfindungsgemäßen Verfahrnes
wird nachfolgend anhand eines einfachen Beispiels erläutert:
In
einem Fahrzeug wird zur Wegmessung ein Radarsystem eingesetzt. Das
Radarsystem ist über
eine Diagnoseschnittstelle mit dem Diagnoseorakel verbunden und
liefert kontinuierlich die aktuellen Daten für Weg und Geschwindigkeit.
Im Diagnoseorakel werden die Ausgabedaten des Radarsystems analysiert.
Weg und Geschwindigkeit werden beispielsweise auf kontinuierlichen
Verlauf innerhalb gegebener Toleranzen geprüft. Solange die Daten des Radarsystems
auf eine korrekte Funktion des Gerätes schließen lassen, werden durch das
Diagnoseorakel keine Aktivitäten
vorgenommen. Treten beispielsweise sprunghafte Veränderungen
der ausgegebenen Geschwindigkeit auf, wird dieses vom Orakel als
Indiz für
fehlerhaftes Verhalten gewertet. Durch das Diagnoseorakel wird in
diesem Fall der Tracelevel für die
Radarausgabe erhöht.
Dieses bewirkt, dass nun neben Berechnungsergebnissen des Radarsystems nämlich Ort
und Geschwindigkeit auch die Radar-Primärdaten vor Filterung und Verarbeitung,
wie beispielsweise die Feldstärke
des Empfangssignals, an die Diagnoseschnittstelle ausgegeben werden.
Mit Hilfe dieser Primärdaten
kann bei späterer
Auswertung die Ursache für
die Fehlfunktion analysiert werden. Durch das Diagnoseorakel wird
die Speicherung aller vom Radarsystem gelieferten Daten veranlasst. Außerdem wird
die aktuelle Systemzeit protokolliert. An den zentralen Diagnosedatenspeicher
des Fahrzeuges wird eine Diagnosemeldung abgesetzt, die den fehlerhaften
Systemzustand des Radarsystems meldet. Die Speicherung der Radardaten
erfolgt über einen
vorgegebenen Zeit raum oder bis das zugrunde liegende Diagnoseereignis
nicht mehr besteht. Mit dem Beenden der Protokollierung wird der
Tracelevel an der Schnittstelle des Radarsystems zum Diagnoseorakel
wieder auf den ursprünglichen
Wert herabgesetzt.