Komponenten

Die Erfindung betrifft ein Verfahren zur rechnergestützten Erfassung von Fehlern beim Ablauf von einem oder mehreren software-basierten Programmen in einem System aus Komponenten, insbesondere in einem Kraftfahrzeug.

In einer Vielzahl von technischen Bereichen, insbesondere auch auf dem Gebiet der Automobiltechnik, wird der Anteil an Software in auszuführenden Funktionen der entsprechenden technischen Anlage bzw. des Fahrzeugs immer komplexer. Im Regelfall werden Software-Programme dabei in einem verteilten System aus mehreren Komponenten ausgeführt, wobei hier und im Folgenden der Begriff der Komponente weit zu verstehen ist und jede Einheit mit einer oder mehreren Funktionalitäten beim Programmablauf umfassen kann. Insbesondere ist eine Komponente eine technische Komponente mit technischer Funktionalität bzw. ein technisches Gerät, wie z.B. ein Steuergerät, mit entsprechender Software bzw. ein Teil dieses Geräts. Ebenso können Komponenten auch Funktionen bzw. Objekte im Sinne einer Programmiersprache betreffen, welche Programmteile innerhalb des Systems ausführen. Eine Komponente kann insbesondere auch eine Software-Komponente im Sinne des bekannten Standards AUTOSAR sein.

Software-Fehler treten beim Ablauf eines Programms immer zur Laufzeit und meist sporadisch auf. Ferner stehen Ursache und Wirkung solcher Fehler oft nicht im zeitlichen Zusammenhang. Dadurch wird die Fehlerbehebung beim Auftreten von Software-Fehlern wesentlich erschwert, da die Software-Fehler nicht reproduziert werden können, die Bedingungen ihres Eintretens nicht nachvollzogen werden können und generell unklar ist, wo die Ursache der Fehler zu suchen ist.

Im Bereich der Fahrzeugdiagnose werden derzeit erkannte Fehler in der Form sog. DTCs (Diagnostic Trouble Codes) in entsprechenden technischen Komponenten bzw. Steuergeraten abgelegt. Zwischen den hierdurch generierten Fehiereinträgen gibt es jedoch keine funktionale Verknüpfung und die Fehler lassen sich lediglich über den Zeitpunkt des Auftretens in Beziehung setzen. Aufgabe der Erfindung ist es deshalb, Fehler beim Ablauf eines Software-Programms in geeigneter Weise zu erfassen, um die erfassten Fehler nachfolgend einer verbesserten Diagnose zum Auffinden der Fehlerursache unterziehen zu können.

Diese Aufgabe wird durch das Verfahren gemäß. Patentanspruch 1 bzw. das Verfahren gemäß Patentanspruch 9 bzw. das System gemäß Patentanspruch 11 bzw. die Diagnosevorrichtung gemäß Patentanspruch 13 gelöst. Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen definiert.

In dem erfindungsgemäflen Verfahren ist den Komponenten des Systems jeweils eine Identifikation zugeordnet und ein jeweiliges ablaufendes Programm ist durch eine Programmidentität spezifiziert. Dabei führt im Ablauf des jeweiligen Programms eine Komponente einen ihr zugeordneten Programmteil aus und die Komponenten rufen sich im Programmablauf ferner zumindest teilweise gegenseitig auf.

In dem erfiπdungsgemäßen Verfahren wird beim Aufruf einer Komponente durch eine andere Komponente die Programmidentität sowie ein Fehlerparameter von der anderen Komponente an die Komponente übermittelt, wobei der Fehlerparameter angibt, ob im Ablauf des Programms zuvor ein Fehler erkannt wurde. Falls eine Komponente beim Ausführen des ihr zugeordneten Programmteils einen Fehler erkennt, speichert die Komponente einen aktiven Fehlereintrag, der die Programmidentität, die Identifikation der Komponente und einen Fehlerstatus enthält, der angibt, ob der erkannte Fehler der erste Fehler im Ablauf des Programms ist. Ein aktiver Fehlereintrag betrifft somit einen Fehler, der in derjenigen Komponente auftritt, in welcher der Fehlereintrag auch gespeichert wird.

Falls in dem erfindungsgemäßen Verfahren eine Komponente, welche eine andere Komponente aufgerufen hat, von der anderen Komponente die Identifikation der anderen Komponente empfängt, speichert die Komponente einen passiven Fehlereintrag, der die Programmidentität, die Identifikation der Komponente und die Identifikation der anderen Komponente enthält. Durch einen passiven Fehiereintrag wird entsprechend spezifiziert, dass der Fehler gemäß dem Fehlereintrag ein Fehler ist, der in einer anderen Komponente als derjenige aufgetreten ist, in welcher der Fehlereintrag gespeichert ist. Der passive Fehlereintrag gibt dabei an, dass zuvor in der Aufrufkette des Programms ein Fehler auf- getreten ist, wobei durch die Speicherung der Identifikation der anderen Komponente die Aufrufkette, in weicher der Fehler aufgetreten ist, nachverfolgt werden kann.

Erfindungsgemäß gibt eine Komponente, weiche einen oder mehrere aktive oder passive Fehlereinträge im Ablauf des Programms speichert, zumindest einmal im Ablauf des Programms die Programmidentität und die Identifikation der Komponente an diejenige Komponente zurück, durch welche die Komponente aufgerufen wurde. Auf diese Weise wird die Propagation von Fehiereinträgen zu deren Nachverfolgung im Programmablauf gewährleistet.

Das erfiπduπgsgemäße Verfahren zeichnet sich dadurch aus, dass durch entsprechend generierte aktive und passive Fehlereinträge sowie der Übermittlung geeigneter Informationen beim gegenseitigen Aufruf der Komponenten Software-Fehler nachverfolgt werden können und auch erkannt werden kann, ob der entsprechende Software-Fehler der erste Fehler im Programmabiauf oder ein potentieller Folgefehler ist, der möglicherweise aus dem ersten Fehler resultiert.

In einer bevorzugten Variante der Erfindung sind die einzeiπen Komponenten Steuergeräte und/oder Teile von Steuergeräten, welche über entsprechende Schnittstellen miteinander kommunizieren, wobei die aktiven und passiven Fehlereinträge in vorgegebenen Speicherbereichen der Steuergeräte gespeichert werden. Ein bevorzugter Anwendungs- fall ist dabei der Ablauf eines Software-Programms in vernetzten Steuergeräten in einem Kraftfahrzeug oder in mehreren miteinander kommunizierenden Kraftfahrzeugen.

In einer weiteren bevorzugten Variante der Erfindung umfasst die Programmidentität eine Identifikation einer auslösenden Komponente, an der das Programm gestartet wird, sowie eine entsprechende Startzeit des Programms.

In einer weiteren Ausführuπgsform des erfindungsgemäßen Verfahrens werden im Falle, dass nach der Ausführung eines Programmteils durch eine Komponente keine Fehler in den anschließend ausgeführten Programmteilen auftreten, an die Komponente von derjenigen Komponente, welche durch die Komponente aufgerufen wurde, die Programmidentität und ein Parameter zurückgegeben, wobei der Parameter die Fehierfreiheit der anschließend ausgeführten Programmteile anzeigt und wobei bei Empfang des Parameters in der Komponente kein passiver Fehlereintrag in der Komponente gespeichert wird. Auf diese Weise erfolgt eine geeignete Rückmeldung in der jeweiligen Komponente, dass nach der Ausführung des ihr zugeordneten Programmteils keine Fehler aufgetreten sind und somit auch kein passiver Fehlereintrag in der Komponente gespeichert werden muss. Der Parameter ersetzt somit die bei Auftreten eines Fehlers zurückgegebene Identifikation der aufgerufenen Komponente.

In einer weiteren Variante des erfindungsgemäßen Verfahrens wird zumindest teilweise im Ablauf des Programms bei jedem Aufruf einer Komponente ein Aufruf-Eintrag in der Komponente gespeichert. Auf diese Weise können auch fehlerfrei ablaufende Aufrufketten in einem Programmablauf erfasst werden. Vorzugsweise erhält ein Aufruf-Eintrag in der Komponente dabei die Identifikation derjenigen Komponente, welche die Komponente aufgerufen hat. Auf diese Weise können auch Aufrufketten von korrekt ablaufenden Programmteilen rekonstruiert werden. Es besteht dabei die Möglichkeit, dass ab dem Auftreten des ersten Fehlers im Ablauf des Programms Aufruf- Ein träge in den jeweiligen Komponenten gespeichert werden. Gegebenenfalls können auch während des gesamten Ablaufs des Programms Aufruf-Einträge hinterlegt werden.

In einer weiteren, besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens wird ein jeweiliger Fehlereintrag (d.h. ein aktiver oder ein passiver Fehlereintrag) in einer Komponente durch ein Feld umfassend eine Mehrzahl von Werten beschrieben, wobei in dem Feld die Programmädentität spezifiziert ist und das Feld ferner einen ersten Wert enthält, der die Identifikation der Komponente spezifiziert, welche den Fehiereintrag speichert, sowie einen zweiten Wert, der die Komponente spezifiziert, in welcher der Fehler aufgetreten ist (entspricht bei einem aktiven Fehlereintrag der Komponente, welche den Fehlereintrag speichert) und einen dritten Wert, der angibt, ob der Fehlereintrag ein passiver Fehiereintrag oder ein aktiver Fehlereintrag ist, wobei im Falle eines aktiven Fehlereintrags der dritte Wert ferner spezifiziert, ob der Fehler der erste Fehler im Ablauf des Programms ist. Die Ausdrücke „erster Wert", „zweiter Wert" und „dritter Wert" spezifizieren dabei lediglich entsprechende Arten von Werten und geben nicht zwangsläufig die Steile an, an der sich der entsprechende Wert im Feld befindet.

In der Variante des erfindungsgemäßen Verfahrens, in der die Programmidentität durch die Identifikation der auslösenden Komponente und die Startzeit festgelegt ist, enthält das Feld zur Beschreibung des Fehlereintrags zwei Werte zur Spezifikation der Programm- identität, wobei einer der Werte die Identifikation der auslosenden Komponente und der andere der Werte die Startzeit darstellt.

Neben dem soeben beschriebenen Verfahren zur Erfassung von Fehlem betrifft die Erfindung ferner ein Verfahren zum Verarbeiten von Fehlern, welche mit diesem Verfahren erfasst wurden. Dabei werden die gespeicherten aktiven und passiven Fehlereinträge ausgelesen und für jede Programmidentität wird aus den dazugehörigen aktiven und passiven Fehlereinträgen ein Fehlerbaum generiert und ausgegeben, wobei in dem Fehlerbaum zumindest die Aufrufketten von aufeinanderfolgend aufgerufenen Komponenten enthalten sind, welche wenigstens eine Komponente mit einem aktiven Fehlereintrag enthalten. Dabei sind in dem Fehlerbaum die Komponenten dahingehend gekennzeichnet, ob in der jeweiligen Komponente im Ablauf des Programms kein Fehler oder der erste Fehler oder ein potentieller Folgefehler aufgetreten ist. Aufgrund dieser Information kann in geeigneter Weise nachverfolgt werden, wie die einzelnen Fehler im Fehlerbaum zusammenhängen. Die späteren, nach dem ersten Fehler aufgetretenen Fehler stellen dabei potentielle Folgefehler dar und es wird durch den Fehlerbaum insbesondere vermittelt, aus welchem ursprünglichen Fehler bzw. aus welchen anderen potentiellen Folgefehlern ein entsprechender Folgefehler entstanden sein könnte. Sollten bei der Erfassung von Fehlern ferner auch die oben beschriebenen Aufruf-Einträge enthalten sein, kann der Fehlerbaum gegebenenfalls auch diejenigen Aufrufketten enthalten, in denen alle Komponenten ihren Programmteil fehlerfrei ausgeführt haben.

Eine weitere Variante des Verfahrens zur Rekonstruktion des Fehlerbaums beruht auf einer Erfassung von Fehlern über Fehlereinträge, welche durch die oben beschriebenen Felder spezifiziert werden. Dabei wird der Fehlerbaum derart generiert, dass ausgehend von jeder Komponente mit einem aktiven Fehlereintrag schrittweise über den ersten und zweiten Wert der Felder der Fehlereinträge jeweilige Aufrufketten von aufeinander folgend aufgerufenen Komponenten bestimmt werden.

Neben den oben beschriebenen Verfahren betrifft die Erfindung ferner ein System aus Komponenten, insbesondere in einem Kraftfahrzeug, wobei das System derart ausgestaltet ist, dass Fehler beim Ablauf von einem oder mehreren software-basierten Programmen mit dem oben beschriebenen Verfahren zur Erfassung von Fehlern ermittelt werden. Darüber hinaus betrifft die Erfindung ein Kraftfahrzeug, welches ein solches System um- fasst.

Ferner betrifft die Erfindung eine Diagnosevorrichtung zum Verarbeiten von mit dem oben beschriebenen Verfahren erfassten Fehlern, wobei die Diagnosevorrichtung derart ausgestaltet ist, dass mit der Vorrichtung das oben beschriebene Verfahren zum Verarbeiten entsprechend erfasster Fehler durchführbar ist.

Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Figuren detailliert beschrieben.

Es zeigen:

Fig. 1 eine schematische Darstellung des Austauschs von informationen in einem Aufruf einer zweiten Komponente durch eine erste Komponente gemäß einer Ausfuhrungsform des erfindungsgemäßen Verfahrens;

Fig. 2 eine schematische Darstellung eines Systems aus Komponenten und deren Interaktion, auf dessen Basis eine Ausführuπgsfαrm des erfindungsgernäßen Verfahrens beschrieben wird;

Fig. 3 bis Fig. 12 schematische Darstellungen, weiche beispielhaft einen Abiauf eines Programms in dem System der Fig. 2 und die dabei verwendete Fehlererfassung basierend auf einer Ausführungsform des erfindungsgemäßen Verfahrens zeigen; und

Fig. 13 eine schematische Darstellung, welche das Auslesen der in dem

Programmablauf gemäß Fig. 3 bis Fig. 12 erfassten Fehler und der darauf basierenden Generieruπg eines Fehlerbaums gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens verdeutlicht.

Nachfolgend werden Ausführungsformen des erfindungsgemäßen Verfahrens basierend auf einem verteilten System aus einer Mehrzahl von Steuergeräten in einem Kraftfahr- zeug beschrieben, wobei die von den einzelnen Steuergeräten auszuführenden Funktionen mittels Software realisiert sind. Dabei wird ein Ablauf eines Software-Programms betrachtet, bei dem sich die einzelnen Steuergeräte gegenseitig aufrufen, wobei gemäß dem Programmabiauf nach Beendigung entsprechender Programmfuπktionen in einem Steuergerät ein anderes Steuergerät aufgerufen wird. Die Steuergeräte stellen Komponenten im Sinne von Anspruch 1 dar und werden deshalb im Folgenden auch als Komponenten bezeichnet.

Die einzelnen Steuergeräte weisen zur Kommunikation definierte Schnittstellen auf und kommunizieren untereinander über das Bussystem des Kraftfahrzeugs. Es kann sich bei den Steuergeräten um beliebige Einheiten zur Ausführung von Funktionalitäten im Fahrzeug handeln, beispielsweise um eine elektronische Motorsteuerung, um die Steuerung der Airbags, die Steuerung elektrischer Stellmotoren, z.B. zur Sitzverstellung, die Steuerung der Klimaanlage im Fahrzeug, die Steuerung der Anzeigeeinheiten im Fahrzeug und dergleichen. Ein Programmablauf in diesem System an Komponenten ist beispielsweise die Aπsteuerung der einzelnen Stellmotoren einer automatischen Sitzversteiiung, welche den Sitz basierend auf einer für eine Person im Fahrzeug hinterlegten vorprogrammierten Sitzeiπstelluπg verstellt.

Bei einem Ablauf eines Software-Programms in dem oben beschriebenen verteilten System aus Komponenten besteht das Problem, dass es keine geeigneten Mechanismen gibt, welche zur Laufzeit des Programms auftretende Software-Fehler derart erfassen, dass eine Fehlerverfolguπg zur Ermittlung der Ursache bzw. des Auslösers der einzelnen Fehler möglich ist. Gemäß den nachfolgend beschriebenen Ausführungsformen der Erfindung wird eine Erfassung von Software-Fehlern und deren Hinterlegung in dem Fehlerspeicher der einzelnen Komponenten derart geschaffen, dass beim späteren Auslesen der Fehler ein geeigneter Fehlerbaum generiert werden kann. Die Erfindung umfasst somit zum einen ein Verfahren, bei dem Software-Fehler onboard im Fahrzeug in geeigneter Weise erfasst werden, und zum anderen ein Verfahren, um die erfassten Software-Fehler offboard zu einem Fehlerbaum zusammenzusetzen.

Fig. 1 zeigt allgemein die Kommunikation zwischen einem aufrufenden Steuergerät CUA (CU = Control Unit) und einem aufgerufenen Steuergerät CUB. Im Folgenden wird ein aufrufendes Steuergerät auch als erstes Steuergerät bzw. erste Komponente und ein auf- gerufenes Steuergerät auch als zweites Steuergerät bzw. zweite Komponente bezeichnet. Es wird dabei im Folgenden davon ausgegangen, dass jede Komponente durch eine eindeutige Identifikation, z.B. eine UUID (UUID = Universal Uπique Ideπtifier) oder eine Soft- ware-ID, identifizierbar ist und im Programmabiauf Aufrufe von einer Komponente durch eine andere auftreten. Darüber hinaus existieren geeignete Mechanismen, um durch die Komponente beim Programmablauf erkannte Software-Fehler in Fehlerspeichern der Komponenten zu hinterlegen. Ferner wird in der hier beschriebenen Ausführungsform der synchrone Aufruf von Komponenten betrachtet, wobei die Erfindung jedoch analog auch auf nicht-synchrone Aufrufe angewendet werden kann.

Gemäß Fig. 1 werden beim Aufruf der zweiten Komponente CUB durch die erste Komponente CUA als zusätzliche Parameter das Parametertripel (a, b, f) übertragen. Der Parameter a bezeichnet dabei die Identifikation derjenigen Komponente, welche ursprünglich das laufende Programm ausgelöst hat. Sofern das Programm an der Komponente CUA beginnt, stimmt der Parameter a mit der Identifikation der Komponente CUA überein. Der Parameter b spezifiziert die Zeit, zu der das Programm bei der auslösenden Komponente gestartet wurde, d.h. zu der die entsprechende Kundenfunktion im Fahrzeug basierend auf dem Programm initiiert wurde. Die Kombination der Parameter a und b charakterisieren somit einen aktuellen Ablauf eines Programms und diese Kombination entspricht einer Programmidentität im Sinne von Anspruch 1. Der Parameter f stellt einen Fehlerparame- ter dar und gibt an, ob zuvor im Ablauf des Programms bereits ein Fehler in einer Komponente aufgetreten ist. Ist zuvor kein Fehler erkannt worden, wird der Fehlerparameter auf 0 gesetzt, ist ein Fehler aufgetreten, ist der Parameter im nachfolgenden Ablauf des Programms auf 1 gesetzt.

Nachdem die aufgerufene Komponente CUB die entsprechenden Programmfunktionen abgearbeitet hat, wird an die erste Komponente CUA ein Return in der Form eines Parameters r sowie die bereits oben erwähnten Parameter a und b zurückgegeben. Der Re- turπ-Wert r ist dabei immer auf 0 gesetzt, wenn in der Komponente CUB kein Fehler erkannt wurde und der Komponente auch nicht von anderen, später aufgerufenen Komponenten das Auftreten eines Fehlers gemeldet wird. In allen anderen Falten enthält der Parameter r als Wert die Identifikation der Komponente CUB. Beim Ablauf des Programms werden entsprechende Fehlereinträge in den Fehlerspeichern der einzelnen Komponenten erzeugt, wobei sowohl aktive Fehlereinträge als auch passive Fehlereinträge in den Fehlerspeϊchem hinterlegt werden. Ein aktiver Fehlereiπtrag wird dabei dann erzeugt, wenn in der entsprechenden Komponente selbst ein Fehler aufgetreten ist, und ein passiver Fehlereintrag wird dann erzeugt, wenn eine Komponente von einer anderen Komponente als Return-Wert r die Identifikation der anderen Komponente empfängt. Als Return-Wert r wird somit immer dann die Identifikation der aufgerufenen Komponente übertragen, wenn in dieser Komponente selbst ein Fehler aufgetreten ist oder wenn die aufgerufene Komponente von derjenigen Komponente, die sie selbst aufruft, einen Return-Wert ungleich 0 empfängt.

In den weiter unten beschriebenen Fig. 5 bis 12 sind entsprechende Fehlereinträge der Komponenten als Vektoren mit fünf Werten in eckigen Klammern angegeben, wobei allgemein der erste Wert des Vektors mit a, der zweite Wert mit b, der dritte Wert mit i, der vierte Wert mit p und der fünfte Wert mit e bezeichnet werden, wie in Fig. 5 entsprechend angedeutet ist. Allgemein kann somit ein Fehlereintrag als Vektor [a, b, i, p, e] geschrieben werden. Dabei entspricht a wiederum der den Programmablauf ursprünglich auslösenden Komponente und b der Startzeit, an der das Programm an der auslösenden Komponente gestartet wird. Demgegenüber bezeichnet i die Identität der Komponente, die den entsprechenden Fehlereintrag gerade speichert. Durch den Parameter p wird die Fehlerherkunft festgelegt. Erkennt eine Komponente selbst einen Software-Fehler, so wird hier die eigene Identität der Komponente eingetragen. Wurde im Return-Wert r, den die betrachtete Komponente von der durch sie aufgerufenen Komponente empfängt, die Identität der aufgerufenen Komponente übermittelt, so wird diese Identität für den Parameter p verwendet. Über den Parameter p wird somit vermittelt, ob ein aktiver Fehlereintrag eines lokal in der betrachteten Komponente aufgetretenen Fehlers vorliegt oder nicht.

Durch den Parameter e wird der Fehiertyp angegeben. Wird in einer Aufrufkette von aufeinander folgenden Komponenten ein Software-Fehler zum ersten Mal entdeckt {„primärer Fehler"), so wird e in der entsprechenden Komponente auf 1 gesetzt. Anschließend wird beim Aufruf der nächsten Komponente der Parameter f auf 1 gesetzt und bleibt auch bei allen nachfolgenden Aufrufen von Komponenten auf 1. Wurde eine Komponente bereits mit f = 1 aufgerufen, so wird beim Erkennen eines Fehlers in der aufgerufenen Komponente e auf 2 gesetzt. Dadurch wird angezeigt, dass ein aufgetretener Fehler ein poten- tieller Folgefehler ist. Wurde von einer aufgerufenen Komponente ein Fehler an die aufrufende Komponente gemeldet (d.h. wird als Parameter r die Identifikation der aufgerufenen Komponente zurückgegeben), so ist ein passiver Fehlerspeichereiπtrag vorzunehmen, bei dem e auf 0 gesetzt wird. Dieser Fehlereintrag zeigt somit an, dass ein Fehler von einer anderen Komponente detektiert wurde. Beim Setzen eines passiven Fehlereintrags muss die entsprechende Komponente ferner dann, wenn sie zuvor noch keinen Return-Wert r ≠ 0 übertragen hat, ihre eigene Identifikation als Return-Wert r an die vorhergehende Komponente zurückgeben. Die Generierung von passiven Fehlereinträgen ist dazu notwendig, dass später die Aufrufreihenfolge der Komponenten bei der Generierung des Fehlerbaums hergestellt werden kann.

Fig. 2 zeigt am Beispiel eines Systems aus zwölf verteilten Steuergeräten CU 1 , CU2

CU12 den Programmablauf basierend auf einer funktionalen Aufrufkette, bei der die Aufrufe bei der auslösenden Komponente CU 1 synchron erfolgen. Die Aufrufe innerhalb des Programmablaufs sind dabei durch entsprechende Pfeile angedeutet, von denen aus ÜbersichtÜchkeitsgründen lediglich einige mit Bezugszeichen P bezeichnet sind. Man erkennt, dass der Programmablauf an der Komponente CU1 als auslösende Komponente startet, Diese Komponente ruft die vier Komponenten CU2, CU3, CU4 und CU5 auf. Anschließend ruft die Komponente CU3 die Komponenten CU7 bis CU8 auf, woraufhin dann die Komponente CU8 die Komponente CU 11 aufruft. Ferner ruft die Komponente CU5 die Komponenten CU9 und CU 10 auf, woraufhin die Komponente CU10 die Komponente CU12 aufruft. In dem Programmablauf der Fig. 2 treten bei der Abarbeitung der Programmteile in den Komponenten CU3, CU7, CU 10, CU 11 und CU12 Fehler auf, welche durch entsprechende gezackte Pfeile Z angedeutet sind.

Anhand des Systems der Komponenten der Fig. 2 und des dargestellten Programmablaufs wird nunmehr eine Ausführungsform zur Erfassung von Software-Fehlern basierend auf entsprechenden Fehiereinträgen sowie dem oben beschriebenen Austausch von Parametern (Fig. 1 ) beschrieben. Im Folgenden bezeichnen die Zahlen 01 , 02, ..., 12 jeweils die Identifikation der entsprechenden Komponente CU 1, CU2, ..., CU 12. Demgegenüber bezeichnet der Buchstabe t den Zeitpunkt des Starts des Programms, d.h. den Auslösezeitpunkt des Programms durch die Komponente CU1. Gemäß Fig. 3 ruft die Komponente CU1 die Komponente CLJ2 mit Parametern a = 01, b = t und f = 0 auf. Gemäß Fig. 4 schickt die Komponente CLJ2 in Antwort auf den Aufruf den Retum-Wert r = 0 sowie die Identifikation 01 der auslösenden Komponente und die Auslösezeit t zurück, denn in der Komponente CU2 ist kein Fehler aufgetreten und die Komponente ruft auch keine nachfolgenden Komponenten mehr auf. Gemäß Fig. 5 ruft die auslösende Komponente CU1 die Komponente CU3 auf. In der Komponente CU3 ist lokal ein Fehler aufgetreten. Demzufolge wird der Fehlereintrag [01, t, 03, 03, 1] erzeugt. Der Parameter p ist auf 03 gesetzt, da der Fehier lokal in der Komponente CU3 aufgetreten ist. Der Parameter e ist auf 1 gesetzt, da dies der erste, im Programmablauf auftretende Fehler ist. Beim Aufruf der Komponente CU3 durch die Komponente CU1 wurde die Identität 01 der auslösenden Komponente CU1 sowie die Auslösezeit t übermittelt, die dann als die ersten beiden Werte im Fehlereintrag übernommen werden, wie durch den Pfeil P' in Fig. 5 angedeutet ist Da nunmehr ein Fehler in der Komponente CU5 aufgetreten ist, wird an die Komponente CU7 neben der Identifikation 01 der auslösenden Komponente CU1 und der Auslösezeit t nunmehr der Parameter f = 1 übermittelt. Anschließend führt die aufgerufene Komponente CU7 ihre Programmfunktionen aus, wobei lokal wiederum ein Fehler auftritt. Als Folge wird der Fehlereintrag [01 , t, 07, 07, 2] erzeugt, wobei durch den Wert p = 07 angezeigt wird, dass es sich um einen lokalen Fehler handelt. Demgegenüber wird durch e = 2 angezeigt, dass der aufgetretene Fehler nicht der erste Fehler im Programmablauf ist, was bedeutet, dass es sich um einen potentiellen Folgefehler handeln kann, der aus dem Fehler einer anderen Komponente resultieren kann.

Wie in Fig. 6 angedeutet ist, meldet die Komponente CU7 nach der Ausführung ihrer Programmfunktionen neben der Identifikation 01 der auslösenden Komponente 01 und der Auslösezeit t den Wert r = 07 zurück, denn in der Komponente CU7 ist ein Fehler aufgetreten. Daraufhin wird der Fehlereintrag [01 , t, 03, 07, 0] in der Komponente CU3 generiert, wobei durch p = 07 und e = 0 angezeigt wird, dass es sich um einen passiven Fehlereintrag handelt, der auf einen von der Komponente CU7 zurückgehenden Fehier stammt. Schließlich wird die Komponente CU8 durch die Komponente CU3 aufgerufen. Dabei wird neben der Identifikation 01 der auslösenden Komponente und der Auslösezeit t der Parameter f = 1 übermittelt. In der Komponente CU8 tritt bei der Programmausführung kein Fehler auf. Schließlich übermittelt die Komponente CU8 die Identifikation 01 der auslösenden Komponente, die Auslösezeit t sowie den Parameter f = 1 im Rahmen des Aufrufs der Komponente CU11 an diese Komponente. In der Komponente CU11 tritt wie- derum ein lokaler Fehler auf. Als Konsequenz wird in der Komponente CU11 der aktive Fehlereintrag [01 , t, 11 , 11 , Z] erzeugt. Dabei zeigt e = 2 an, dass es sich in der Komponente CU 12 um einen potentiellen Folgefehler handelt

Wie in Fig. 7 angedeutet ist, wird als Folge des in CU12 aufgetretenen Fehlers die Identifikation 11 der Komponente CU 11 neben der Identifikation 01 der auslösenden Komponente und der Auslösezeit t an die Komponente CU8 zurückgegeben. Diese erzeugt wiederum einen passiven Fehlereintrag in der Form [01 , t, QS, 11, O]. Als Folge wird neben der Identifikation 01 der auslösenden Komponente und der Auslösezeit t die Identität 08 der Komponente CU8 an die Komponente CU3 zurückgegeben. Analog erfolgt dann nach der Generierung des passiven Fehlereintrags [01, t, 03, 08, 0] in der Komponente CU3 die Rückgabe der Identifikation 03 der Komponente CU3 zusammen mit der Identifikation 01 der auslösenden Komponente und der Auslösezeit t an die Komponente CU1. Als Folge wird der passive Fehlereintrag [01 , t, 01 , 03, 0] in CU1 generiert.

Gemäß Fig. 8 ruft die auslösende Komponente CU1 die Komponente CU4 auf und überträgt dabei ihre Identifikation 01, die Auslösezeit t und den Parameter f = 1. Da in der Komponente CU4 kein Fehler auftritt und sich das Programm von dort aus nicht weiter fortsetzt, wird gemäß Fig. 9 von der Komponente CU4 neben der Identifikation 01 der auslösenden Komponente und der Auslösezeit t der Parameter r = 0 an CU1 zurückgegeben. Als Konsequenz wird in der Komponente CU 1 kein weiterer Fehlereintrag generiert.

Gemäß Fig. 10 ruft die Komponente CU1 die Komponente CU5 auf, welche fehlerfrei ihre Programmfunktionalitäten ausführt und anschließend die Komponente CU9 aufruft, weiche ebenfalls fehlerfrei ihre Programmfuπktionen ausführt. Dabei werden wiederum die Identifikation 01 der auslösenden Komponente, die Ausiösezeit t und f = 1 übertragen. Da in dieser Programmkette kein Fehler aufgetreten ist, werden auch keine aktiven Fehlereinträge in den Komponenten CU1 , CU5 und CU9 erzeugt.

In Fig. 11 ist die Rückgabe des entsprechenden Parameterwerts r = 0 von der Komponente CU9 an die Komponente CU5 wiedergegeben. Ferner zeigt Fig. 11 den Aufruf der Komponente CU10 durch die Komponente CU5, wobei wiederum die Identifikation 01 der auslösenden Komponente und die Auslösezeit t sowie der Parameter f = 1 übertragen werden. Da in der Komponente CU 10 ein lokaler Fehler auftritt, wird dort der aktive Feh- lereintrag [01 , t, 10, 10, 2] hinterlegt. Die Komponente CU10 ruft dann die Komponente CU 12 auf und überträgt hierbei wiederum die Identifikation 01 der auslösenden Komponente, die Auslösezeit t sowie den Parameter f = 1. In der Komponente CU 12 tritt dann bei der Programmausführung ein weiterer lokaler Fehler auf, so dass dort der aktive Fehlereintrag [01 , t, 12, 12, 2] gespeichert wird.

Wie sich aus Fig. 12 ergibt, wird nach der Ausführung der Programmfunktionen der Komponente CU 12 aufgrund des aufgetretenen Fehlers in der Komponente CU12 neben der Identifikation 01 der auslösenden Komponente und der Auslösezeit t die Identifikation 12 der Komponente CU12 an die Komponente CU10 zurückgegeben. Da der Parameter r ungleich 0 ist, wird nunmehr ein passiver Fehlereintrag in der Form [01, t, 10, 12, 0] in der Komponente CU10 generiert. Aufgrund der Fehlereinträge in CU10 wird der Parameter r = 10 neben der Identifikation 01 der auslösenden Komponente und der Auslösezeit t an die Komponente CU5 übertragen. Da der Parameter r wieder ungleich 0 ist, wird auch in der Komponente CU5 ein entsprechender passiver Fehlereintrag [01 , t, 05, 10, 0] gespeichert. Aufgrund dieses passiven Fehlereintrags wird nunmehr der Parameter r = 05 neben der Identifikation 01 der auslösenden Komponente und der Auslösezeit t an die Komponente CU1 zurückgegeben. Auch in der Komponente CU 1 wird dann wegen r ≠ 0 ein passiver Fehlereintrag in der Form [01, t, 01 , 05, 0] generiert.

In Fig. 12 ist die Programmausführung dann beendet Fig. 12 zeigt somit alle im gerade beschriebenen Programmablauf in den einzelnen Komponenten gespeicherten Fehlereinträge. Diese Fehlereinträge werden anschließend mit einer entsprechenden Diagnosevorrichtung aus den Fehlerspeichern der Komponenten ausgelesen, Anschließend wird ein entsprechender Fehlerbaum generiert, wie nachfolgend anhand von Fig. 13 beschrieben wird.

Nach Auslesen der Fehlereinträge ergibt sich zunächst folgende Liste für die Fehlereinträge der einzelnen Komponenten:

CU1 : [01 , t, 01 , 03, 0] [01 , t, 01 , 05, 0]

CU2: -

CU3: [01, t, 03, 03, 1] [01 , t, 03, 07, 0] [01 , t, 03, 08, 0]

CU4: - CU5: [01 , t, 05, 10, 0]

CU6: -

CU7: [01, t, 07, 07, 2]

CU8: [01 _r t, 08, 1 1 , 0]

CU9: -

CU10: [01, t, 10, 10, 27 [01 , t, 10, 12, 0]

CUU: [01, t, 11, 11, 2]

CU12: /m, t, 12, 12, 2]

In der obigen Listen sind dabei alle Fehlereinträge mit e = 2, welche potentielle Folgefehler darstellen, kursiv wiedergegeben. Ferner ist der Fehlereintrag, der den ersten Fehler im Programmablauf spezifiziert, d.h. für den e = 1 gilt, fett gedruckt. Dieser Fehlereintrag ist in der Komponente CU3 hinterlegt. Zur Generierung des Fehierbaums werden zu ^¬ nächst als Einstiegspunkte entsprechender Aufrufketten diejenigen Komponenten bestimmt, welche einen lokalen Fehlereiπtrag enthalten, d.h. welche bei sich selbst einen Fehler beim Programmablauf erkannt haben. Dies sind gemäß der obigen Liste alle Komponenten, welche zumindest einen Fehlereintrag enthalten, dessen Parameter e ungleich 0 ist. Dies sind gemäß der obigen Liste der Komponenten CLJ3, CU7, CU10, CU11 und CU 12.

Ausgehend von den Identifikationen der Komponenten mit zumindest einem Fehlereintrag mit e ≠ 0 wird dann eine entsprechende Aufrufkette derart zusammengesetzt, dass für eine jeweilige Komponente nach denjenigen Komponenten gesucht wird, welche als vier ^¬ ten Wert im Fehlereiπtrag die Identifikation der jeweiligen Komponente enthält. Das heißt, es wird ausgehend von dem dritten Wert i der Fehlereinträge in der jeweiligen Komponen ^¬ te nach einer Komponente gesucht, welche einen Fehiereintrag enthält, dessen vierter Wert dem dritten Wert der jeweiligen Komponente entspricht. Für die Komponente CLJ 12 ergibt sich dann, dass die Komponente CLJ10 einen solchen Fehlereintrag, nämlich [01, t, 10, 12, 0] enthält. Es wird dann mit der aufgefundenen Komponente analog verfahren, d.h. es wird wieder eine Komponente gesucht, die ausgehend von den Fehlereinträgen der gerade aufgefundenen Komponente einen Fehlereintrag enthält, der einen vierten Wert aufweist, der dem dritten Wert der Fehlereinträge der gerade aufgefundenen Kom ^¬ ponente entspricht. Dies wird solange fortgesetzt, bis man schließlich an der auslösenden Komponente CU 1 ankommt, Gemäß dem obigen Beispiel wird somit ausgehend von der gefundenen Komponente CU10 dann nach Komponenten gesucht, welche Einträge enthalten, die als vierten Wert die Identifikation 10 aufweisen. Dies ist gemäß der obigen Liste der Fall für die Komponente CU5. Ausgehend von dieser Komponente wird nach einer Komponente gesucht, welche einen Eintrag enthält, der als vierten Wert die Identifikation 05 aufweist. Dies ist die auslösende Komponente CU 1. Auf diese Weise wird die Kette eines lokalen Fehlers geeignet zurückverfoigt.

Gemäß Fig. 13 ergeben sich somit für die einzelnen Identifikationen 03, 07, 10, 11 und 12 der jeweiligen Komponenten CU3, CU7, CU10, CU11 und CU12 die Aufrufketten A1 bis A5. Diese Aufrufketten werden dann in der Reihenfolge umgekehrt und zu einem Fehlerbaum FB zusammengefasst, wie durch den Pfeil P" angedeutet ist. Über die Reihenfolge der in einer Komponente abgelegten Fehtereinträge ergibt sich die Reihenfolge der Aufrufe. Zum Beispie! wird in Komponenten CU1 zuerst ein Fehlereintrag für CU3, danach ein Fehlereintrag für CU5 abgelegt. Daraus ergibt sich, dass CU1 zuerst die Komponente CU3 und danach CU5 aufgerufen hat. In diesem Fehlerbaum werden ausgehend von der Identifikation 01 in der obersten Hierarchieebene Verbindungen zu den gemäß den umgekehrten Aufrufketten in den darunter liegenden Hierarchieebenen vorhandenen Identifikationen gebildet. In dem Fehlerbaum der Fig. 13 schließen sich somit an die Identifikation 01 in umgekehrter Richtung der Aufrufketten A1 bis A5 die Identifikationen 03 und 05 an. Die zweite Hierarchieebene des Fehlerbaums FB enthält folg lieh die Identifikationen 03 und 05. In gleicherweise wird dann nach Identifikationen in der nächsten Hierarchieebene gesucht. Gemäß den Aufrufketten der Fig. 13 ergibt sich dabei, dass die Identifikation 03 sowohl mit der Identifikation 07 als auch mit der Identifikation 08 verbunden ist. Demgegenüber ist die Identifikation 05 nur mit der Identifikation 10 verbunden. Das heißt, der Fehlerbaum FB verzweigt sich von der Identifikation 03 zu den Identifikationen 07 und 08. Demgegenüber verzweigt sich der Fehlerbaum von der Identifikation 05 nur zu der Identifikation 10. Für die darauf folgende Hierarchieebene ergibt sich, dass die Identifikation 08 mit der Identifikation 10 und die Identifikation 10 mit der Identifikation 12 verbunden ist. Die Identifikation 07 steht demgegenüber bereits am Anfang der entsprechenden Aufrufkette A2. Somit verzweigt sich der Fehlerbaum ausgehend von der Identifikation 08 nur zur Identifikation 11 und von der Identifikation 10 nur zu der Identifikation 12.

Da für die einzelnen Komponenten bekannt ist, ob in diesen Komponenten kein Fehler (e = 0) bzw. ein Fehler zum ersten Mal (e = 1) bzw. ein potentieller Folgefehler (e = 2) auf- getreten ist, wird diese Information in dem Fehlerbaum FB geeignet codiert. Dies ist in dem Fehlerbaum der Fig. 13 dadurch angedeutet, dass die dick gedruckte Identifikation 03 die Komponente spezifiziert, an welcher ein Fehler im Programmablauf das erste Ma! aufgetreten ist, die kursiv gedruckten Identifikationen 07, 10, 11 und 12 Komponenten spezifizieren, bei denen potentielle Folgefehler aufgetreten sind, und die normal gedruckten Identifikationen 01 , 05 und 08 Komponenten spezifizieren, in denen kein Fehler aufgetreten ist.

Wie sich aus der Beschreibung des obigen Ausführungsbeispiels ergibt, kann mit der dargelegten Hinterlegung entsprechender Fehlereinträge beim Programmablauf in geeigneter Weise ein Fehlerbaum generiert werden, aus dem abgelesen werden kann, aus welchen vorhergehenden Fehlern ein potentieller Folgefehler generiert sein könnte. Man erkennt dabei in Fig. 13 insbesondere, dass die Fehler in der Komponente CU7 und CU11 ihre Ursache möglicherweise in dem Fehler in der Komponente CU3 haben und dass die Fehler in den Komponenten 10 und 12 nicht mit den Fehlern in den Komponenten CU3, CU7 und CU11 im Zusammenhang stehen.

Die oben beschriebene Ausführungsform des erfindungsgemäßen Verfahrens kann in geeigneter Weise abgewandelt werden. Insbesondere können alle Aufrufe von Komponenten erfasst werden. In diesem Fall wird bei jedem Aufruf einer Komponente ein entsprechender Eintrag in der Komponente vorgenommen, der in diesem Sinne keinen Fehlereintrag darstellt, sondern lediglich spezifiziert, dass die Komponente aufgerufen wurde. Gemäß dem im Vorangegangenen beschriebenen Format der Fehlereinträge kann ein solcher Eintrag beispielsweise dadurch spezifiziert werden, dass er als dritten und vierten Wert die Identifikation der aufgerufenen Komponente und als fünften Wert den Wert e = 0 enthält Der erste bzw. zweite Wert entspricht dabei wiederum der Identifikation 01 der auslösenden Komponente bzw. der Auslösezeit t. Um dabei eine komplette Rekonstruktion auch von fehlerfrei abgelaufenen Aufrufketten zu gewährleisten, muss ferner bei jedem Aufruf die Identifikation der aufrufenden Komponente in der aufgerufenen Komponente hinterlegt werden.

Gemäß der obigen Abwandlung besteht zum einen die Möglichkeit, dass alle Aufrufe immer ab dem Start des Programms aufgezeichnet werden. Jedoch kann in einer Alternative auch vorgesehen sein, dass die Aufzeichnung aller Aufrufkette erst ab dem ersten Fehler- fall gestartet wird, d.h. wenn der Parameter f den Wert 1 annimmt In diesem Fall stehen keine Informationen über die Aufrufketten vor dem Eintreten des ersten Fehlers zur Verfügung, jedoch wird weniger Speicherplatz benötigt, als wenn die Aufrufe ab dem Programmstart erfasst werden.

Das im Vorangegangenen beschriebene Verfahren zum Erfassen von Fehlern und Erzeugung von Fehlerbäumeπ weist eine Reihe von Vorteilen auf. insbesondere werden mit dem Verfahren aussagekräftige Fehlerbilder geliefert, bei denen funktional zusammengehörige Software-Fehler zusammeπgefasst werden können. Neben dem funktionalen Zusammenhang wird dabei unterschieden zwischen dem erstmaligen Auftreten eines Software-Fehlers sowie potentiellen Folgefehlern, die sich daraus ergeben können. Damit ist sichergestellt, dass sporadische Software-Fehler besser nachvollziehbar und reproduzierbar sind. Das Verfahren selbst ist einfach und effizient. Es ist keinerlei Statusinformation in den Komponenten zu halten. Es ist lediglich der Speicherplatz für die Ablage der Fehlerinformation vorzusehen. Das Verfahren arbeitet permanent und somit unabhängig von Fehlervorfällen. Damit ist gewährleistet, dass im Fehlerfali die Buskommuπikation im Fahrzeug nicht ansteigt und somit Buslast und Jitter deterministisch bleiben.