DE10056413A1 - Diagnosemodul und Verfahren zum Erzeugen eines Simulationsmodells für eine Diagnose - Google Patents

Abstract

Bei einem Diagnosemodul für die Diagnose eines Fahrzeugsystems werden Ausgangssignale eines Systemmodells unter Berücksichtigung einer Funktionshierarchie und einer Komponentenhierarchie weiterverarbeitet. Als Ergebnis der Weiterverarbeitung stehen Funktionszustände anwenderorientierter Funktionen und deren Kritikalität sowie Informationen bezüglich der kleinsten tauschbaren Einheit zur Verfügung. DOLLAR A Anwendung zum Beispiel bei Kraftfahrzeugen.

Description

Die Erfindung betrifft ein Diagnosemodul für die Diagnose eines Fahrzeugsystems sowie ein Verfahren zum Erzeugen eines Simula­ tionsmodells für die On-Board-Diagnose eines Fahrzeugsystems.

Aus der Patentschrift DE 197 42 448 C1 ist eine Diagnoseein­ richtung bekannt, die eine Funktions- und eine Komponentenhie­ rarchie eines Gesamtsystems verwendet. Funktions- und Komponen­ tenhierarchie sind über die jeweils unterste Ebene miteinander verbunden. Die Diagnoseeinrichtung bietet die Möglichkeit, Aus­ sagen zur Nutzungsbeeinträchtigung von Funktionen des Gesamt­ systems zu treffen sowie die zu einer fehlerhaften Komponente gehörende kleinste tauschbare Einheit zu ermitteln.

Bekannt sind auch Modellierungs- und Simulationswerkzeuge, mit denen ein Systemmodell, das Systemkomponenten und deren Wirk­ verbindung durch Signal-, Material- und Energieflüsse sowie messbare Systemgrößen abbildet, automatisch erzeugt werden kann. Ein solches Systemmodell kann für eine Fehlerdiagnose verwendet werden. Ein solches Modellierungs- und Simulations­ werkzeug ist beispielsweise in W. Seibold, "A Model Based Diag­ nostic and Simulation System in Practical Use - The Concept of rodon", Fifth international workshop of principels of diagnos­ tic, Oktober 1994, beschrieben. Das Verhalten eines Systems wird dort durch Übertragungsfunktionen und Wertetabellen be­ schrieben. Systemmodellkomponenten entsprechen dabei nicht not­ wendigerweise realen Komponenten des Systems, beispielsweise dann, wenn im Systemmodell mathematische Gleichungen Wirkungsabhängigkeiten zwischen Komponenten nachbilden und eine Be­ schreibung dieser Effekte erforderlich wird. Diagnoseaussagen eines solchen Systemmodells sind für eine anwenderorientierte Diagnose nur bedingt geeignet.

Mit der Erfindung soll eine anwenderorientierte Diagnose für Fahrzeugsysteme ermöglicht werden.

Erfindungsgemäß ist hierzu ein Diagnosemodul für die Diagnose eines Fahrzeugsystems vorgesehen, mit Mitteln zum Erfassen von messbaren Systemgrößen des Fahrzeugsystems, Mitteln zum Erstel­ len einer Fehlerdiagnose anhand der erfassten messbaren System­ größen und zum Ausgeben von Fehlerdiagnosefunktionszustandssig­ nalen von Systemmodellkomponenten mit den Werten "defekt" (0), "in Ordnung" (1) oder "keine Aussage" (01) und Mitteln zum Ver­ arbeiten der Fehlerdiagnosefunktionszustandssignale unter Be­ rücksichtigung einer Funktionshierarchie, die Funktionen des Fahrzeugsystems in mehreren Ebenen darstellt, wobei anhand der Fehlerdiagnosefunktionszustandssignale Funktionszustände der Funktionen ermittelt und angegeben werden können, die die Werte "defekt", "in Ordnung" oder "keine Aussage" einnehmen.

Durch die Verarbeitung der von der Fehlerdiagnose ausgegebenen Fehlerdiagnosefunktionszustandssignale mit Hilfe einer Funkti­ onshierarchie kann das Ergebnis der Fehlerdiagnose auf anwen­ derorientierte Funktionen des Fahrzeugsystems übertragen wer­ den, nämlich Funktionen, beispielsweise Leuchten von Scheinwer­ fern, an denen ein Fahrer interessiert ist. Durch Berücksichti­ gung einer Funktionshierarchie mit mehreren Ebenen sind eventu­ elle Fehlfunktionen auf verschiedenen Abstraktionsebenen be­ kannt, so dass ein Diagnoseergebnis auf einen jeweiligen Anwen­ der abgestimmt werden kann. Beispielsweise sind Fahrer und Ser­ vicetechniker an verschiedenen Funktionsebenen interessiert. Die Mittel zum Erstellen einer Fehlerdiagnose und die Mittel zum Verarbeiten der Fehlerdiagnosefunktionszustandssignale sind vorzugsweise durch Software realisiert und bspw. auf einem Fahrzeugsteuergerät implementiert.

In Weiterbildung der Erfindung ist vorgesehen, dass die Mittel zum Erstellen einer Fehlerdiagnose die Fehlerdiagnose anhand der erfassten messbaren Systemgrößen und eines Systemmodells erstellen, das das Fahrzeugsystem und Wirkverbindungen im Fahr­ zeugsystem durch Signal-, Material- und Energieflüsse sowie die messbaren Systemgrößen abbildet. Die Verwendung eines Systemmo­ dells ermöglicht die Bereitstellung weiterverarbeitbarer Signa­ le, die eine Aussage über den Fehlerzustand des Systems enthal­ ten.

In Weiterbildung der Erfindung ist vorgesehen, dass die Mittel zum Erstellen einer Fehlerdiagnose die Fehlerdiagnose anhand der erfassten messbaren Systemgrößen und abgespeicherter Tabel­ len erstellen, in denen Werte der Systemgrößen mit Funktionszu­ ständen von Systemmodellkomponenten verknüpft sind. Auf diese Weise erhält man durch eine sogenannte Symptomanalyse ebenfalls eine Aussage über einen Fehlerzustand des Systems. Beispiels­ weise sind Werte von Systemgrößen, die auf ein Motorruckeln hindeuten, mit einem fehlerhaften Zustand der Einspritzanlage verknüpft.

In Weiterbildung der Erfindung ist vorgesehen, dass bei einem Funktionszustand "defekt" ein Funktionscode ausgegeben wird, der die Ebene der fehlerhaften Funktion und deren Kritikalität beschreibt. Durch die ausgegebene Kritikalität einer fehlerhaf­ ten Funktion wird die schlimmstmögliche Auswirkung der fehler­ haften Funktion, und mithin das, was für einen Anwender von In­ teresse ist, beschrieben.

In Weiterbildung der Erfindung sind bei dem erfindungsgemäßen Diagnosemodul Mittel zum Verarbeiten der Fehlerdiagnosefunkti­ onszustandssignale unter Berücksichtigung einer Komponentenhie­ rarchie vorgesehen, die reale Komponenten des Fahrzeugsystems in mehreren Ebenen darstellt, wobei anhand der Systemdiagnose­ funktionszustandssignale Komponentenzustände der realen Kompo­ nenten ermittelt und ausgegeben werden können, die die Werte "defekt", "in Ordnung" oder "keine Aussage" einnehmen. Durch diese Maßnahmen können verdächtige Komponenten festgestellt werden. Da die Komponentenhierarchie reale Komponenten des Fahrzeugsystems abbildet, ist eine anwenderorientierte Aussage, die tatsächlich vorhandene und eventuell tauschbare Komponenten beschreibt, möglich.

In Weiterbildung der Erfindung ist vorgesehen, dass bei einem Komponentenzustand "defekt" ein Komponentencode ausgegeben wird, der eine der fehlerhaften Komponente zugeordnete, aus re­ alen Komponenten bestehende kleinste tauschbare Einheit be­ schreibt.

Durch diese Maßnahmen kann ausgehend von einem, in der System­ diagnose festgestellten Fehlerzustand eine zugeordnete kleinste tauschbare Einheit festgestellt werden. Dadurch weiß ein Fahrer oder Servicetechniker nicht nur, welche Funktion des Fahrzeug­ systems gefährdet oder ausgefallen ist, ihm wird auch ein Hin­ weis darauf gegeben, welche Komponenten überhaupt ausgetauscht werden können. Im Falle einer Glühbirne für ein Rücklicht ent­ spricht eine Komponente der Komponentenhierarchie beispielswei­ se der kleinsten tauschbaren Einheit, wohingegen im Falle des Rücklichts Fassung, Verbinder und Leitungen einzelne Komponen­ ten darstellen, die aber nur gemeinsam als kleinste tauschbare Einheit Rückleuchte gewechselt werden können.

In Weiterbildung der Erfindung sind Mittel zum Auswählen einer Ebene der Funktionshierarchie und zum Visualisieren des auf der ausgewählten Ebene ausgegebenen Funktionscodes und des ausgege­ benen Komponentencodes vorgesehen. Durch diese Maßnahme wird eine Anzeigeeinheit bereitgestellt, mit der die gewünschte Abs­ traktionsebene für die Anzeige des Diagnoseergebnisses gewählt werden kann. Beispielsweise wird ein Servicetechniker eine an­ dere Abstraktionsebene als ein Fahrer wählen.

In Weiterbildung der Erfindung sind Mittel zum Zuordnen eines Klartextstrings und/oder einer Abbildung zu dem auf der ausgewählten Ebene ausgegebenen Funktionscode und dem ausgegebenen Komponentencode vorgesehen. Auf diese Weise kann eine Fehler­ meldung im Klartext und eventuell anhand einer Abbildung ausge­ geben werden und dadurch dem Anwender das Diagnoseergebnis ü­ bermittelt werden.

Das der Erfindung zugrundeliegende Problem wird auch durch ein Verfahren zum Erzeugen eines Simulationsmodells für die Diagno­ se eines Fahrzeugsystems gelöst, bei dem folgende Schritte vor­ gesehen sind: Anhand eines Systemmodells, das das Fahrzeugsys­ tem und Wirkverbindungen im Fahrzeugsystem durch Signal-, Mate­ rial- und Energieflüsse sowie messbare Systemgrößen abbildet, Ermitteln von Systemmodellkomponenten, die keiner realen Kompo­ nente des Fahrzeugsystems entsprechen, und Ermitteln von Anzahl und Art der realen Komponenten des Fahrzeugsystems, Ermitteln von die realen Komponenten betreffende hierarchische Informati­ on aus dem Systemmodell, Modellieren der realen Komponenten, nämlich Elementarkomponenten und aus Elementarkomponenten ge­ bildete übergeordnete Komponenten, und hierarchisches Vernetzen dieser Komponenten zu einer Komponentenhierarchie mit mehreren Ebenen.

Auf diese Weise kann ein Simulationsmodell für die Diagnose au­ tomatisch aus einem vorhandenen Systemmodell erzeugt werden. Dies ist insbesondere deshalb vorteilhaft, da Systemmodelle während der Konstruktion eines Fahrzeugs ohnehin erstellt wer­ den. Indem solche vorhandenen Systemmodelle genutzt werden, wird der Aufwand zum Erzeugen eines Simulationsmodells für die Diagnose bedeutend verringert. Beim Modellieren der realen Kom­ ponenten des Fahrzeugsystems kann jede Komponente auch einer kleinsten tauschbaren Einheit zugeordnet werden, mit der zusam­ men die Komponente ausgetauscht werden kann.

In Weiterbildung der Erfindung sind folgende Schritte vorgese­ hen: Anhand des Systemmodells, Ermitteln von Funktionen des Fahrzeugsystems sowie die Funktionen des Fahrzeugsystems betreffende hierarchische Informationen, Modellieren der Funktionen, nämlich Elementarfunktionen und durch disjunktive und/oder konjunktive Verknüpfung der Elementarfunktionen gebil­ dete übergeordnete Funktionen, und hierarchisches Vernetzen der Funktionen zu einer Funktionshierarchie mit mehreren Ebenen. Bei der Modellierung der Funktionen kann jeder Funktion ein Kritikalitätswert zugeordnet werden, der eine Bewertung der schlimmstmöglichen Auswirkung des Ausfalls einer Funktion ent­ hält.

In Weiterbildung der Erfindung sind folgende Schritte vorgese­ hen: Permutieren aller Funktionszustände in einer Ebene der Funktionshierarchie und Erstellen von Funktionscodes für jede Permutation, Zuordnen von Klartextstrings und/oder Abbildungen zu den Funktionscodes jeder Permutation und Abspeichern der Funktionscodes jeder Permutation und der zugeordneten Klartext­ strings und/oder Abbildungen. Auf diese Weise entsteht für jede mögliche Konstellation von defekten Funktionen in einer Ebene ein Funktionscode, wobei jeder mögliche Code mit einem Klar­ textstring, der die Information im Klartext enthält, sowie ei­ ner Abbildung, die die Informationen grafisch dargestellt, kor­ respondiert. Die abgespeicherten Funktionscodes und zugeordne­ ten Klartextstrings sowie Abbildungen können mit einem Code, der die kleinste tauschbare Einheit beschreibt, zusammengesetzt und dann ausgegeben oder angezeigt werden.

In Weiterbildung der Erfindung sind folgende Schritte vorgese­ hen: Erzeugen einer Simulationsdatenbasis durch Verändern von Eingangssignalen für das Systemmodell, Versetzen von ausgewähl­ ten Komponenten in den Defektzustand und Ermitteln der zugeord­ neten Fehlerdiagnosefunktionszustandssignale und Vergleichen der Simulationsdatenbasis mit den für einen bestimmten Fehler­ diagnosefunktionszustand ermittelten Funktionscodes der Ebenen. Durch diese Maßnahmen kann das automatisch erstellte, aus der Funktions- und der Komponentenhierarchie bestehende Funktions­ diagnosemodell automatisch simuliert und verifiziert werden. Das verifizierte Simulationsmodell wird schließlich in einen, zu der Zielplattform kompatiblen Programmcode umgesetzt. Zielplattform eines Simulationsmodells für die On-Board-Diagnose eines Fahrzeugsystems ist beispielsweise ein Steuergerät im Fahrzeugsystem.

In Weiterbildung der Erfindung sind folgende Schritte vorgese­ hen: Erzeugen einer Simulationsdatenbasis durch Verändern von Einganssignalen für das Systemmodell, Vorgeben von Klartext­ strings und/oder Abbildungen und Ermitteln der zugeordneten Funktionscodes und/oder Komponentencodes der Ebenen und Ver­ gleichen des Simulationsdatenbasis mit den für einen bestimmten Klartextstring und/oder eine bestimmte Abbildung ermittelten Funktionscodes und/oder Komponentencodes der Ebenen. Auf diese Weise kann ein Verifizierung in umgekehrter Richtung erfolgen, nämlich umgekehrt zu der bei einer tatsächlichen Diagnose ge­ wählten Richtung von Funktionszuständen zu der Ausgabe eines Klartextstrings. Gerade bei heutigen hoch komplexen Fahrzeug­ systemen, bei denen zahlreiche Komponenten für einen Fehlerzu­ stand verantwortlich sein können, ermöglicht diese Vorgehens­ weise eine effiziente und gründliche Überprüfung des Simulati­ onsmodells.

Weitere Merkmale und Vorteile der Erfindung ergeben sich aus den Ansprüchen und der folgenden Beschreibung im Zusammenhang mit den Zeichnungen. In den Zeichnungen zeigen:

Fig. 1 eine schematische Darstellung eines Diagnosemoduls für die On-Board-Diagnose eines Fahrzeugsystems,

Fig. 2 eine schematische Darstellung des erfindungsgemäßen Verfahrens zum Erzeugen eines Simulationsmodells für die On-Board-Diagnose,

Fig. 3 eine schematische Darstellung zur Erläuterung einer Komponente der Funktionshierarchie,

Fig. 4 eine erste Verknüpfungskomponente, wie sie in höheren Ebenen der Funktions- oder Komponentenhierarchie ver­ wendet wird, und

Fig. 5 eine weitere Verknüpfungskomponente zur Verwendung in höheren Ebenen der Funktions- oder Komponentenhierar­ chie.

Bei einem erfindungsgemäßen Diagnosemodul, das in der Fig. 1 schematisch dargestellt ist, sind zunächst Mittel 10 zum Erfas­ sen von messbaren Systemgrößen eines Fahrzeugsystems vorgese­ hen. Die erfassten Systemgrößen werden an Mittel 12 zum Er­ stellen einer Fehlerdiagnose übergeben. Ein Systemmodell ist durch Komponenten 14, 16 und 18 angedeutet, wobei die Komponen­ te 14 einen Schalter, die Komponente 16 eine Leitung und die Komponente 18 eine Glühlampe repräsentiert. Es ist dabei fest­ zustellen, dass die Komponenten 14, 16 und 18 das Verhalten des Fahrzeugsystems durch Energieflüsse und messbare Systemgrößen abbilden. So fließt ein elektrischer Strom vom Schalter über die Leitung zur Glühlampe und eine ordnungsgemäße Funktion der Komponenten kann anhand der Systemgrößen Widerstand, Strom und Spannung festgestellt werden. Die Komponenten 14, 16 und 18 bilden aber beispielsweise nicht zwingend Stecker und Buchsen an der Leitung und dem Schalter oder eine Fassung einer Rück­ leuchte mit der Glühlampe ab. Das Ergebnis der Fehlerdiagnose ist damit nicht immer direkt auf die realen Komponenten im Fahrzeug, sondern auf die Komponenten des Systemmodells bezogen und daher nur bedingt für eine anwenderorientierte Diagnose ge­ eignet. Ein Ergebnis der Fehlerdiagnose kann auch nur eine Aus­ sage über den ordnungsgemäßen oder fehlerhaften Zustand der Mo­ dellkomponenten 14, 16 oder 18 liefern, jedoch keine Aussage über die beeinträchtigte Funktion, z. B. Anzeigen Bremslicht oder Richtungsblinken. Das Systemmodell ist in Form eines Pro­ grammcodes auf einem Fahrzeugsteuergerät implementiert.

Die Komponenten 14, 16 und 18 weisen jeweils einen Eingang IN und einen Ausgang OUT auf, wobei der Ausgang OUT der Komponente 14 mit dem Eingang IN der Komponente 16 und der Ausgang OUT der Komponente 16 mit dem Eingang IN der Komponente 18 verbunden ist. Dies repräsentiert den Stromfluss durch den Schalter, die Leitung und die Glühlampe. Jede Komponente 14, 16 und 18 weist auch einen Ausgang FD auf, an dem ein Fehlerdiagnosefunktions­ zustandssignal ausgegeben wird. Im Unterschied zum Ausgabesig­ nal einer konventionellen Fehlerdiagnose kann das Fehlerdiagno­ sefunktionszustandssignal lediglich die Werte "defekt" (0) oder "in Ordnung" (1) oder "keine Aussage" (01) annehmen, wobei der Wert "keine Aussage" durch eine Kombination von 0 und 1 reprä­ sentiert ist. Die Fehlerzustandsausgänge konventioneller Sys­ temmodelle können dahingegen die Werte "fehlerhaft" und "nor­ mal" einnehmen, wobei diese Werte eventuell mit einer Wahr­ scheinlichkeit bewertet sind. Solche gewichteten Fehlerzu­ standssignale sind nicht ohne weiteres logisch weiterzuverar­ beiten. Durch Vorsehen des Ausgangs FD mit den Werten 0 und 1 sowie einer Kombination von 0 und 1 wird bei der Erfindung die gewünschte Logik für nachfolgende Schlussfolgerungsverfahren bereitgestellt.

Die Fehlerdiagnosefunktionszustandssignale werden von den Aus­ gängen FD an Mittel 20 übergeben, die eine Funktionsdiagnose durchführen. Hierzu weisen die Mittel 20 zum einen Mittel 22 auf, die die Fehlerdiagnosefunktionszustandssignale unter Be­ rücksichtigung einer Funktionshierarchie verarbeiten. Zum ande­ ren sind Mittel 24 vorgesehen, die die Fehlerdiagnosefunktions­ zustandssignale unter Berücksichtigung einer Komponentenhierar­ chie verarbeiten. Auch die Mittel 20, 22 und 24 sind in Form eines Programmcodes auf einen Fahrzeugsteuergerät implemen­ tiert.

Die Funktionshierarchie stellt Funktionen des Fahrzeugsystems in mehreren Ebenen dar, wobei die unterste Ebene der Funktions­ hierarchie durch Elementarfunktionen gebildet ist, die in der Fig. 1 als Funktion 1 bis 4 bezeichnet sind. Solche Elementar­ funktionen sind beispielsweise Leiten einer Zuleitung, Leuchten einer Lampe, Verbinden eines Steckers und Treiben eines Treibers im Steuergerät. Höhere Ebenen der Funktionshierarchie wer­ den durch Verknüpfung der Elementarfunktionen gebildet, wobei eine disjunktive und/oder konjunktive Verknüpfung vorgesehen sein kann. Übergeordnete Funktionen auf höheren Ebenen der Funktionshierarchie sind beispielsweise Funktionen wie Rich­ tungsblinken, Bremsaktion Anzeigen und Schlusslicht Anzeigen. So müssen für eine übergeordnete Funktion Rückfahrlicht Anzei­ gen beispielsweise die Funktionen Treiben (Steuergerät), Ver­ binden (Stecker), Leuchten (Glühbirne), Leiten (Zuleitung) und Leiten (Masse) erfüllt und konjunktiv verknüpft (UND) sein. Bei redundanten Systemen, wo Funktionen mehrfach vorhanden sind, tauchen disjunktive Verknüpfungen (ODER) auf. Übergeordnete Funktionen der Funktionshierarchie sind in der Fig. 1 durch die Funktion 5 und die Funktion 6 dargestellt.

Falls defekte Funktionen des Systems gesucht sind, werden als Eingangsinformation für die Funktionsdiagnose die aus der Feh­ lerdiagnose ermittelten Fehlerdiagnosefunktionszustandssignale verwendet. Die Eingangsinformation setzt sich dann durch logi­ sche Verknüpfungen in die verschiedenen hierarchischen Ebenen fort. Somit können in jeder Ebene der Funktionshierarchie die betroffenen Funktionen angezeigt werden. Dadurch erfolgt eine Umsetzung der Ergebnisse der Fehlerdiagnose auf anwenderorien­ tierte Funktionen, wodurch die einen Anwender tatsächlich inte­ ressierenden Funktionsbeeinträchtigungen ermittelt und darge­ stellt werden können.

Durch die Komponentenhierarchie wird das Fahrzeugsystem in ein­ zelne Komponenten eingeteilt, nämlich Elementarkomponenten auf einer niedrigsten Ebene der Komponentenhierarchie und überge­ ordnete Komponenten in höheren Ebenen. In der Darstellung der Fig. 1 stellen die Komponenten 1 bis 4 Elementarkomponenten dar, beispielsweise Kabel, Glühwendel, Glühbirne und Verbinder. Übergeordnete Komponenten werden durch Verknüpfung von Elemen­ tarkomponenten gebildet, beispielsweise werden zwei Glühwendeln auf einer höheren Ebene zu einer übergeordneten Einheit Glühbirne verknüpft oder Kabel, Verbinder und Glühbirne ergeben auf einer höheren Ebene eine übergeordnete Komponente Heckleuchte.

Sowohl die Funktionshierarchie als auch die Komponentenhierar­ chie sind aus Labelkomponenten und Verknüpfungskomponenten auf­ gebaut. Ein Beispiel einer Labelkomponente ist in der Fig. 3 dargestellt.

Die Labelkomponente 30 der Fig. 3 repräsentiert die Funktion "Leiten" und ist mit der Kennzeichnung W1 versehen. Eine am Eingang IN anliegende Zustandsinformation für höhere Ebenen wird von der Labelkomponente 30 zum Ausgang OUT durchge­ schleift. Die Labelkomponente 30 stellt eine Attributsinforma­ tion am Ausgang DIAG bereit. Für den Zustand "in Ordnung" lie­ fert die Labelkomponente 30 am Ausgang DIAG als Attributsinfor­ mation den Wert 0. Ist keine Aussage möglich wird am Ausgang DIAG eine Kombination der Werte 0 und 1 ausgegeben. Im Fehler­ fall, d. h. im Zustand "defekt", wird am Ausgang DIAG ein Funk­ tionscode bereitgestellt, der die Ebene der fehlerhaften Funk­ tion und deren Kritikalität beschreibt. Beispielsweise lautet der Funktionscode 39 für Ebene 3 und Kritikalität 9. Kritikali­ tät bezeichnet die schlimmstmögliche Auswirkung der fehlerhaf­ ten Funktion auf das Gesamtsystem. Komponenten der Komponenten­ hierarchie können ebenfalls durch Labelkomponenten dargestellt werden. Elementarfunktionen auf der untersten Ebene der Funkti­ onshierarchie und Elementarkomponenten auf der niedrigsten Ebe­ ne der Komponentenhierarchie sind stets durch Labelkomponenten dargestellt. Komponenten höherer Ebenen sind mit Hilfe einer Labelkomponente und einer Verknüpfungskomponente dargestellt, wobei die Verknüpfungskomponente mehrere Eingangssignale kon­ junktiv und/oder disjunktiv miteinander verknüpft.

In der Fig. 4 ist eine erste Verknüpfungskomponente darge­ stellt, die vier Eingangssignale IN1 bis IN4 in der Art und Weise eines ODER-Glieds verknüpft. Die Eingangssignale an den Eingängen IN1 bis IN4 und das Ausgangssignal am Ausgang OUT können nur die Werte 1 für "in Ordnung" und 0 für "defekt" an­ nehmen.

In der Fig. 5 ist eine Verknüpfungskomponente 34 dargestellt, die die Eingangssignale IN1 bis IN4 in der Art und Weise eines UND-Gliedes verknüpft. Verknüpfungskomponenten können beliebige logische Verknüpfungen repräsentieren.

Unter erneuter Bezugnahme auf die Fig. 1 geben die Mittel 22 über Modellverbindungen 40 einen Funktionscode, der die Ebene einer fehlerhaften Funktion und deren Kritikalität beschreibt, an eine Anzeigeeinheit 42 aus. Die Mittel 24 geben einem Kompo­ nentencode, der eine der fehlerhaften Komponente zugeordnete kleinste tauschbare Einheit beschreibt, über Modellverbindungen 44 ebenfalls an die Anzeigeeinheit 42 aus. Die Modellverbindun­ gen 40 und 44 repräsentieren die Übergabe von Werten innerhalb eine Programms.

Die Anzeigeeinheit 42 hat die Aufgabe, die parallel zur Verfü­ gung stehenden Diagnoseinformationen aus der Funktionsdiagnose, nämlich die Funktionscodes auf den Modellverbindungen 40 und die Komponentencodes auf den Modellverbindungen 44, zu einer Fehlermeldung zusammenzusetzen und diese dann anzuzeigen. Mit Hilfe eines Ebenenwählschalters 46 in der Anzeigeeinheit 42, der durch einen Programmcode realisiert ist, kann eine ge­ wünschte Ebene der Funktionshierarchie ausgewählt werden, deren Funktionscodes angezeigt werden sollen. Damit kann mit Hilfe des Ebenenwählschalters 46 ein gewünschter Abstraktionsgrad der angezeigten Diagnoseergebnisse ausgewählt werden. Beispielswei­ se wird ein Fahrer einen relativ hohen Abstraktionsgrad wählen, beispielsweise die Ebene 1, da er nur an übergeordneten Funkti­ onen, beispielsweise Fahrlicht oder Rücklicht Anzeigen, inte­ ressiert ist. Ein Servicetechniker wird dahingegen eine niedri­ gere Abstraktionsebene, beispielsweise die Ebene 2, wählen, da er an hierarchisch niedrigeren Informationen interessiert ist, beispielsweise ob eine Glühbirne nicht leuchtet, ein Kabel nicht leitet oder gar der Treiber eines Steuergeräts keinen passenden Befehl abgibt.

Die über die Modellverbindungen 44 übertragenen Komponentenco­ des bezeichnen die den fehlerhaften Komponenten zugeordneten kleinsten tauschbaren Einheiten, die in der Anzeigeeinheit 42 in einem Pufferspeicher LRU (least replaceable unit) abgelegt werden. Beispielsweise ist ein Treiber im Steuergerät keine kleinste tauschbare Einheit, sondern ist als Unterkomponente des Steuergeräts nur mit diesem zusammen tauschbar. Die Glüh­ birne des Rückfahrlichts bildet hingegen schon auf der nied­ rigsten Ebene der Komponentenhierarchie eine kleinste tauschba­ re Einheit und ist somit mit keiner anderen Komponente ver­ knüpft. In der Anzeigeeinheit 42 werden die Funktionscodes der ausgewählten Ebene und die Komponentencodes mit den kleinsten tauschbaren Einheiten zusammengesetzt und einem Klartextstring zugeordnet, der für jeden möglichen Funktionscode bzw. Kompo­ nentencode eine Klartextbeschreibung bereitstellt. Die zusam­ mengesetzten Funktions- und Komponentencodes und zugeordnete Klartextstrings werden schließlich einem Ausgabepuffer 48 über­ geben und entweder in einem Display 50 zur Anzeige gebracht oder zur Weiterverarbeitung ausgegeben. Werden daher bei vorge­ gebener defekter Funktion verdächtige Komponenten gesucht, kön­ nen anhand des zugehörigen Funktionscodes alle verdächtigen Komponenten in der Komponentenhierarchie, eventuell zusammen mit der kleinsten tauschbaren Einheit, ermittelt werden. Mit Ausnahme des Displays 50 ist die Anzeigeeinheit 42 als Pro­ grammcode auf einem Fahrzeugsteuergerät implementiert.

In der Fig. 2 ist eine Prozesskette zum Erzeugen eines Simula­ tionsmodells im Überblick dargestellt. Ausgehend von Informati­ onen wie einem Schaltplan, einer K-Matrix und einem Lastenheft wird in konventioneller Weise in einem Schritt 52 ein Systemmo­ dell 54 erzeugt. In einem Schritt 56 wird mit einem Modellgene­ rator das Systemmodell 54 überarbeitet, indem die Systemmodell­ komponenten einen zusätzlichen Ausgang erhalten, der mit lediglich drei definierten Zuständen anzeigt, ob eine Systemmodell­ komponente defekt oder in Ordnung ist oder ob keine Aussage über deren Zustand möglich ist. Dieser Ausgang ist für die lo­ gische Weiterverarbeitung erforderlich. Das auf diese Weise ü­ berarbeitete Systemmodell mit FD-Ausgang ist mit dem Bezugszei­ chen 58 bezeichnet. Im Schritt 56 wird auch ein Funktionsdiag­ nosemodell 60 erzeugt, das die in Bezug auf die Fig. 1 erläu­ terte Funktions- und Komponentenhierarchie umfasst.

Zur Erzeugung des Funktionsdiagnosemodells 60 greift der Mo­ dellgenerator im Schritt 56 auf das Systemmodell 54 sowie auf die Information zu, die im Schritt 52 für die ursprüngliche Mo­ dellierung des Systemmodells 54 verwendet wurde. Das Systemmo­ dell 54 wird zunächst analysiert, und es werden Systemmodell­ komponenten ermittelt, die nicht zwingend einer realen Kompo­ nente des Fahrzeugsystems entsprechen, beispielsweise keinem realen Bauteil aus dem Schaltplan zugeordnet werden können. Herausgefiltert werden dadurch Komponenten, die nur der exakten Modellierung des Fahrzeugsystems dienen, aber keiner realen Komponente des Fahrzeugsystems entsprechen. Im Schritt 56 wird auch Anzahl und Art der realen Komponenten des Fahrzeugsystems ermittelt und darüber hinaus wird hierarchische Information aus dem Systemmodell 54 und den Informationen aus dem Schritt 52 entnommen. Beispielsweise können aus einem Schaltplan überge­ ordnete Komponenten, wie Leuchteinheit, Steuergerät, entnommen werden und hierarchische Information kann beispielsweise auch der Unterteilung des Systemmodells 54 in Teilsysteme entnommen werden.

Bei der Modellierung der realen Komponenten im Schritt 56 wer­ den einerseits Elementarkomponenten und andererseits aus Ele­ mentarkomponenten gebildete übergeordnete Komponenten model­ liert. Elementarkomponenten sind, wie zuvor erläutert, bei­ spielsweise Verbinder, Kabel, Glühwendel, wohingegen übergeord­ nete Komponenten, beispielsweise eine Leuchteinheit, aus der Verknüpfung mehrerer Elementarkomponenten gebildet sind. Anhand der zuvor ermittelten hierarchischen Information erfolgt im Schritt 56 auch eine hierarchische Vernetzung der modellierten Komponenten zu der Komponentenhierarchie mit mehreren Ebenen, wie sie in Fig. 1 dargestellt ist.

In ähnlicher Weise werden anhand des Systemmodells 54 und even­ tuell unter Heranziehung weiterer Informationen aus dem Schritt 52 Elementarfunktionen und übergeordnete Funktionen des Fahr­ zeugsystems im Schritt 56 modelliert und zu der Funktionshie­ rarchie mit mehreren Ebenen vernetzt, die in der Fig. 1 darge­ stellt ist.

Ebenfalls im Schritt 56 werden von dem Modellgenerator diejeni­ gen Daten erzeugt, die für eine Anzeigeeinheit benötigt werden und mit dem Bezugszeichen 62 bezeichnet sind. Diese Daten 62 werden durch Permutieren aller Funktionszustände in einer Ebene der Funktionshierarchie und Erstellen von Funktionscodes für jede Permutation erzeugt. Für jede mögliche Permutation oder jede mögliche Konstellation von defekten Funktionen in einer Ebene der Funktionshierarchie entsteht dadurch ein Funktionsco­ de, der bei Vorliegen der entsprechenden Funktionszustände in der Anzeigeeinheit abgerufen werden kann. Darüber hinaus umfas­ sen die Daten 62 für die Anzeigeeinheit auch Komponentencodes, die die jeweils kleinste tauschbare Einheit, zu der eine spe­ zielle Komponente gehört, angeben. Jedem Funktionscode und je­ dem Komponentencode der Daten 62 wird ein Klartextstring und eine Abbildung zugeordnet, um ein Diagnoseergebnis in hörbarer oder lesbarer Form anzuzeigen.

Nach Erstellen des Systemmodells mit FD-Ausgang 58, des Funkti­ onsdiagnosemodells 60 und der Daten 62 für die Anzeigeeinheit wird das somit erstellte Simulationsmodell in einem Schritt 64 simuliert und verifiziert. Hierzu werden Eingangssignale für das Systemmodell mit FD-Ausgang 58 verändert und ausgewählte Systemmodellkomponenten in den Defektzustand versetzt. Die dann ausgegebenen Fehlerdiagnosefunktionszustandssignale werden zu­ sammen mit den Eingangssignalen und den Defektzuständen der ausgewählten Komponenten in einer Simulationsdatenbasis 66 abgelegt. Anhand der Simulationsdatenbasis 66 wird im Schritt 64 darüber hinaus die korrekte Funktion des Funktionsdiagnosemo­ dells 60 überprüft, indem die Simulationsdatenbasis mit den für einen bestimmten Fehlerdiagnosefunktionszustand ermittelten Funktions- und Komponentencodes der Ebenen verglichen wird.

Eine Überprüfung des Simulationsmodells erfolgt auch dadurch, dass Klartextstrings und Abbildungen aus der Anzeigeeinheit 62 vorgegeben werden und davon ausgehende Funktionscodes und Kom­ ponentencodes der Ebenen ermittelt und mit der Simulationsda­ tenbasis verglichen werden. Durch diese Verifizierung in umge­ kehrter Richtung kann das Simulationsmodell wirkungsvoll über­ prüft werden.

Nach Abschluss des Simulations- und Verifikationsschritts 64 ist das Simulationsmodell fertiggestellt und kann in einen mit einer Zielplattform kompatiblen Programmcode umgesetzt werden. Hierzu wird in einem Schritt 68, der mit Modellanalysator und Codegenerator bezeichnet ist, das Simulationsmodell in einen C- Code übersetzt. Zusätzliche Programmteile können ebenfalls als C-Code hinzugefügt werden, und ein Compiler/Linker übersetzt den C-Code in einen Hexadezimalcode, der dann in ein Steuerge­ rät 70 eines Fahrzeugsystems geladen und für eine On-Board- Diagnose verwendet werden kann. Das Simulationsmodell für eine On-Board-Diagnose eines Fahrzeugsystems kann auf die beschrie­ bene Art und Weise automatisch aus dem zur Verfügung stehenden Systemmodell 54 und weiteren Informationen aus dem Schritt 52 erstellt werden.

Claims (13)

1. Diagnosemodul für die Diagnose eines Fahrzeugsystems mit
Mitteln zum Erfassen von messbaren Systemgrößen des Fahr­ zeugsystems,
Mitteln zum Erstellen einer Fehlerdiagnose anhand der er­ fassten messbaren Systemgrößen und zum Ausgeben von Fehlerdiag­ nosefunktionszustandssignalen von Systemmodellkomponenten mit den Werten "defekt" (0), "in Ordnung" (1) oder "keine Aussage" (01) und
Mitteln zum Verarbeiten der Fehlerdiagnosefunktionszustands­ signale unter Berücksichtigung einer Funktionshierarchie, die Funktionen des Fahrzeugsystems in mehreren Ebenen darstellt, wobei anhand der Fehlerdiagnosefunktionszustandssignale Funkti­ onszustände der Funktionen ermittelt und ausgegeben werden kön­ nen, die die Werte "defekt", "in Ordnung" oder "keine Aussage" einnehmen.

2. Diagnosemodul nach Anspruch 1, dadurch gekennzeichnet, dass die Mittel zum Erstellen einer Fehlerdiagnose die Fehlerdiagno­ se anhand der erfassten messbaren Systemgrößen und eines Sys­ temmodells erstellen, das das Fahrzeugsystem und Wirkverbindun­ gen im Fahrzeugsystem durch Signal-, Material- und Energieflüs­ se sowie die messbaren Systemgrößen abbildet.

3. Diagnosemodul nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Mittel zum Erstellen einer Fehlerdiagnose die Fehlerdiagno­ se anhand der erfassten messbaren Systemgrößen und abgespeicherter Tabellen erstellen, in denen Werte der Systemgrößen mit Funktionszuständen von Systemmodellkomponenten verknüpft sind.

4. Diagnosemodul nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass bei einem Funktionszustand "defekt" ein Funktionscode ausgege­ ben wird, der die Ebene der fehlerhaften Funktion und deren Kritikalität beschreibt.

5. Diagnosemodul nach einem der vorstehenden Ansprüche, gekennzeichnet durch
Mittel zum Verarbeiten der Fehlerdiagnosefunktionszu­ standssignale unter Berücksichtigung einer Komponentenhierar­ chie, die reale Komponenten des Fahrzeugsystems in mehreren E­ benen darstellt, wobei anhand der Systemdiagnosefunktionszu­ standssignale Komponentenzustände der realen Komponenten ermit­ telt und ausgegebnen werden können, die die Werte "defekt", "in Ordnung" oder "keine Aussage" einnehmen.

6. Diagnosemodul nach Anspruch 5, dadurch gekennzeichnet, dass bei einem Komponentenzustand "defekt" ein Komponentencode aus­ gegeben wird, der eine aus realen Komponenten bestehende kleinste tauschbare Einheit beschreibt, der die fehlerhafte Komponente zugeordnet ist.

7. Diagnosemodul nach einem der vorstehenden Ansprüche, gekennzeichnet durch Mittel zum Auswählen einer Ebene der Funk­ tionshierarchie und zum Visualisieren des auf der ausgewählten Ebene ausgegebenen Funktionscodes und/oder des ausgegebenen Komponentencodes.

8. Diagnosemodul nach Anspruch 7, gekennzeichnet durch Mittel zum Zuordnen eines Klartextstrings und/oder einer Abbildung zu dem auf der ausgewählten Ebene ausgegebenen Funktionscode und/oder dem ausgegebenen Komponentencode.

9. Verfahren zum Erzeugen eines Simulationsmodells für die Diagnose eines Fahrzeugsystems, mit folgenden Schritten:

• - Anhand eines Systemmodells, das das Fahrzeugsystem und Wirk­ verbindungen im Fahrzeugsystem durch Signal-, Material- und E­ nergieflüsse sowie messbare Systemgrößen abbildet, Ermitteln von Systemmodellkomponenten, die keiner realen Komponente des Fahrzeugsystems entsprechen, und Ermitteln von Anzahl und Art der realen Komponenten des Fahrzeugsystems,
• - Ermitteln von die realen Komponenten betreffende hierarchi­ sche Information aus dem Systemmodell,
• - Modellieren der realen Komponenten, nämlich Elementarkompo­ nenten und aus Elementarkomponenten gebildete übergeordnete Komponenten, und
• - Hierarchisches Vernetzen dieser Komponenten zu einer Kompo­ nentenhierarchie mit mehreren Ebenen.

10. Verfahren nach Anspruch 9, gekennzeichnet durch die Schritte:

• - Anhand des Systemmodells, Ermitteln von Funktionen des Fahr­ zeugsystems sowie die Funktionen des Fahrzeugsystems betreffen­ de hierarchische Informationen,
• - Modellieren der Funktionen, nämlich Elementarfunktionen und durch disjunktive und/oder konjunktive Verknüpfung der Elemen­ tarfunktionen gebildete übergeordnete Funktionen, und
• - Hierarchisches Vernetzen der Funktionen zu einer Funktions­ hierarchie mit mehreren Ebenen.

11. Verfahren nach Anspruch 10, gekennzeichnet durch die Schritte:

• - Permutieren aller Funktionszustände in einer Ebene der Funk­ tionshierarchie und Erstellen von Funktionscodes für jede Per­ mutation,
• - Zuordnen von Klartextstrings und/oder Abbildungen zu den Funktionscodes jeder Permutation und
• - Abspeichern der Funktionscodes jeder Permutation und der zu­ geordneten Klartextstrings und/oder Abbildungen.

12. Verfahren nach einem der Ansprüche 9 bis 11, gekennzeich­ net durch die Schritte:

• - Erzeugen einer Simulationsdatenbasis durch Verändern von Eingangssignalen für das Systemmodell,
• - Versetzen von ausgewählten Komponenten in den Defektzustand und Ermitteln der zugeordneten Fehlerdiagnosefunktionszustands­ signale und
• - Vergleichen der Simulationsdatenbasis mit den für einen be­ stimmten Fehlerdiagnosefunktionszustand ermittelten Funktions­ codes und/oder Komponentencodes der Ebenen.

13. Verfahren nach einem der Ansprüche 9 bis 12, gekennzeichnet durch die Schritte:

• - Erzeugen einer Simulationsdatenbasis durch Verändern von Ein­ gangssignalen für das Systemmodell,
• - Vorgeben von Klartextstrings und/oder Abbildungen und Ermit­ teln der zugeordneten Funktionscodes und/oder Komponentencodes der Ebenen und
• - Vergleichen der Simulationsdatenbasis mit den für einen be­ stimmten Klartextstring und/oder eine bestimmte Abbildung er­ mittelten Funktionscodes und/oder Komponentencodes der Ebenen.