DE102016216728A1

DE102016216728A1 - Fehlerdiagnose in einem Bordnetz

Info

Publication number: DE102016216728A1
Application number: DE102016216728.6A
Authority: DE
Inventors: Thomas Königseder; Albrecht Neff
Original assignee: Bayerische Motoren Werke AG
Current assignee: Bayerische Motoren Werke AG
Priority date: 2016-09-05
Filing date: 2016-09-05
Publication date: 2018-03-08

Abstract

Die Erfindung betrifft ein Verfahren zur Fehlerdiagnose in einem Bordnetz eines Kraftfahrzeugs und daran angeschlossene externe Systeme (z.B. Backend, CE-Devices). Die Erfindung betrifft ferner eine entsprechend eingerichtete Protokolleinrichtung zur Fehlerdiagnose sowie ein Fahrzeug aufweisend die Protokolleinrichtung. Ferner wird ein Computerprogrammprodukt vorgeschlagen, mit Steuerbefehlen, welche das Verfahren implementieren beziehungsweise die vorgeschlagene Protokolleinrichtung betreiben.

Description

Die Erfindung betrifft ein Verfahren zur Fehlerdiagnose in einem Bordnetz eines Kraftfahrzeugs. Die Erfindung betrifft ferner eine entsprechend eingerichtete Protokolleinrichtung zur Fehlerdiagnose sowie ein Fahrzeug aufweisend die Protokolleinrichtung. Ferner wird ein Computerprogrammprodukt vorgeschlagen, mit Steuerbefehlen, welche das Verfahren implementieren beziehungsweise die vorgeschlagene Protokolleinrichtung betreiben.
DE 19 836 126 A1 zeigt ein bekanntes Kfz-Steuergerät, welches in seinem Programmspeicher Fehlerdiagnoseroutinen enthält, mit denen mehrere Baugruppen oder Komponenten des Kraftfahrzeugs (bspw. Sensoren oder Aktuatoren) regelmäßig auf ihre ordnungsgemäße Funktion überprüft werden.
DE 10 2008 044 405 A1 zeigt eine Protokolleinheit, die dazu ausgebildet ist, während einer Betriebsphase der Steuereinheit Fahrzeug- und/ oder Unfalldaten in dem in der Datenrekordereinheit angeordneten flüchtigen Speicher aufzuzeichnen.
DE 197 00 353 A1 zeigt für die Analyse des Betriebszustandes eines Kraftfahrzeugs ein Diagnosesystem, welches von Sensoren Zustandsdaten über Geschwindigkeit, Motordrehzahl, Betriebstemperatur und auch über Umgebungsparameter auswertet. Um notwendige Steueroperationen abzuleiten, werden mit dem Diagnosesystem alle Prozessparameter mittels einer Datenverarbeitungsanlage erfasst und über einen Soll-Ist-Vergleich so verarbeitet, dass sicherheitsrelevante gefährliche Zustände mit unstabilem Systemverhalten erkannt und angezeigt werden können.
Eine Diagnose in Fahrzeugsystemen basiert gemäß herkömmlicher Verfahren primär auf Fehlerspeichereinträgen, also gespeicherte Fehlercodes, die vor einer Diagnose bekannt und definiert sein müssen. Diese werden in einzelnen Steuergeräten in Ihrem Speicher abgelegt, wenn in dem Steuergerät lokal ein Fehler erkannt wird. Oftmals wird in einer Kommunikationsnachricht, z.B. auf dem CAN-Bus, die vom Fehler betroffenen Ausgangssignale des Steuergeräts auf „fehlerhaft“, z.B. 0xFF, gesetzt.
Fehler in Fahrzeugsystemen sind derzeit primär nur über die jeweils lokalen Fehlerspeichereinträge zu identifizieren und müssen zum Fertigungszeitpunkt des Fahrzeugs definiert sein. Für eine im Fahrzeug laufende Funktion ist die Fehlfunktion einer anderen (im Netzwerk verteilten) Funktion des Fahrzeugs, die die erste Funktion als Input benötigt, oft nur über ein recht generisches Fehlersignal (z.B: 0xFF oder sog. Qualifier) erkennbar. Rührt ein Fehler aus einer verketteten Ausführung von Teilfunktionen einer Funktion über mehrere Steuergeräte im verteilten Fahrzeug-System her oder gar im Fahrzeug-System in Verbindung mit dem Backend, ist die kausale Kette von Fehlerursache bis Fehlerauswirkung im Fahrzeugsystem und oder Fahrzeugsystem mit Backendsystem z.T. nur schwierig zu rekonstruieren.
Zum Teil wird nur die Fehlerauswirkung erkannt, nicht aber die Ursache, oder aber umgekehrt, es ist eine Ursache bekannt, aber unklar wie sich diese im System ausgewirkt hat. Gerade die Verkettung und Entwicklung des Fehlers durch das System kann verborgen bleiben. Außerdem ist eine Einbeziehung des Backends in die Fehler und Fehlerketten bei einer Funktionsausführung historisch nicht zentraler Bestandteil des automotiven Diagnosekonzepts.
Ein Nachteil des Standes der Technik ist also, dass eine verteilte Funktion oftmals den genauen Grund nicht kennt, warum in der Ausführungskette im verteilten Bordnetz in anderen verteilten Teilfunktionen ein Fehler aufgetreten ist.
Automotive Systeme, Steuergeräte und vernetzte Funktionalitäten im Fahrzeug werden immer komplexer. Diagnose und Analyse werden dadurch schwieriger und unterliegen höheren Anforderungen.
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zu schaffen, das es ermöglicht, eine genauere Fehleranalyse bei verteilten Funktionen zu ermöglichen. Es ist ferner eine Aufgabe der vorliegenden Erfindung, eine Protokolleinrichtung sowie ein Fahrzeug aufweisend die Protokolleinrichtung bereitzustellen. Es ist eine weitere Aufgabe der vorliegenden Erfindung ein Computerprogrammprodukt bereitzustellen, mit Steuerbefehlen, welche das vorgeschlagene Verfahren implementieren beziehungsweise die vorgeschlagene Protokolleinrichtung betreiben.
Demgemäß wird ein Verfahren zur Fehlerdiagnose in einem Bordnetz eines Kraftfahrzeugs vorgeschlagen, aufweisend die Schritte des Erstellens eines Ausführungsgraphs, der über vernetzte Steuergeräte im Bordnetz und ggf. auch bis in ein mit dem Fahrzeug verbundenes Backend hinein verteilte Teil-Funktionen einer Funktion durch Registrieren von Schnittstellenaktivitäten (z.B. Signalaufrufen) zwischen Teil-Funktionen (und/ oder zwischen den diese Teil-Funktionen ausführenden Steuergeräten) und der Nutzung einer Statusinformation aus den jeweiligen Teil-Funktionen (und/ oder der diese Teil-Funktion ausführenden Steuergeräten) sowie eines Bereitstellens zumindest eines Teils des Ausführungsgraphs an eine Diagnoseeinheit (und/ oder die die Gesamtfunktion steuernde Teil-Funktion), wobei der Teil des Ausführungsgraphs eine registrierte fehlerhafte Teil-Funktion (und/ oder das diese Teil-Funktion ausführende Steuergerät) aufweist.
Hierbei kann ein Auslesen der Statusinformation auch ein aktives Melden der jeweiligen Komponente umfassen. Ein Auslesen ist somit keinesfalls einschränkend auszulegen, sondern soll vielmehr generell ein Entgegennehmen oder Hinterlegen von Signalaufrufen umfassen.
Die Erfindung schlägt somit ein Verfahren zur Fehlerdiagnose in einem Bordnetz eines Kraftfahrzeugs vor, aufweisend ein Erstellen eines Ausführungsgraphs des Bordnetzes mittels Registrierens von Signalaufrufen von Steuergeräten des Bordnetzes und ein Auslesen einer Statusinformation aus jeweils jedem der Steuergeräte sowie ein Bereitstellen zumindest eines Teils des Ausführungsgraphs an eine Diagnoseeinheit, wobei der Teil des Ausführungsgraphs ein registriertes fehlerhaftes Steuergerät aufweist.
Demgemäß wird insbesondere ein Verfahren zur Fehlerdiagnose in einem Bordnetz eines Kraftfahrzeugs vorgeschlagen, aufweisend die Schritte:

– Erstellen eines Ausführungsgraphs der Teil-Funktionen (und/ oder der diese Teil-Funktionen ausführenden Steuergeräte des Bordnetzes) durch a1) Registrieren von Signalaufrufen/ Signalübertragungen von Steuergeräten/ Teil-Funktionen des Bordnetzes, und/ oder a2) statisches Hinterlegen von Informationen zu möglichen Ausführungsgraphen zentral in der Protokolleinrichtung (oder Hinterlegung in einem anderen mit der Protokolleinrichtung z.B. über Kommunikationsverbindungen verbundenen Datenspeicher, z.B. auch im Backend), z.B. über zur Entwurfszeit des Fahrzeugs bekanntes/ festgelegtes – Abhängigkeitsinformation der Teil-Funktionen untereinander und/ oder – Information darüber, welche Teil-Funktion auf welchem Steuergerät partitioniert ist und/ oder – Information darüber, welche Teil-Funktion welche der Botschaften/Signale versendet/empfängt und/ oder – Information, an welchen Signalen man eine Fehlfunktion oder ein Problem in einer Teilfunktion erkennt und/ oder Information über Betriebs- bzw. Aktivierungszustände von Funktionen und/ oder a3) Bereitstellen der Ausführungsgraphen durch die Teil-Funktionen selbst, z.B. indem jede Teil-Funktion weiß, von welchen weiteren Teil-Funktionen sie abhängig ist. Diese Teil-Ausführungsgraphen/ Abhängigkeiten werden der Beobachtungseinheit übermittelt (z.B. im Fehlerfall genau der vom Fehlerfall betroffene Teil-Ausführungsgraph) oder von dieser bei den Steuergeräten/ Teil-Funktionen abgefragt;
– Nutzen von Statusinformation aus den jeweiligen Steuergeräten bzw. Teil-Funktionen durch Abfragen und/ oder aktives Melden der Statusinformationen von Steuergeräten bzw. Teil-Funktionen und/ oder Auswerten der in den Signalaufrufen/Signal-Übermittlungen enthaltenen Status- bzw. Fehler-Informationen (z.B. Fehlerwerte oder sogenannte Qualifier-Werte, die den aktuellen Betriebszustand einer Funktion (z.B. Funktion OK, Funktion nicht OK, Funktion eingeschränkt, Funktion aktiv/ inaktiv); sowie
– Bereitstellen zumindest eines Teils des Ausführungsgraphs an eine Diagnoseeinheit und/ oder ein Teil-Funktion des Fahrzeugs, wobei der Teil des Ausführungsgraphs einen registrierten Fehler eines Steuergeräts oder einer Teil-Funktion aufweist bzw. auch mehrerer Teil-Funktionen einer Ausführungskette von Teil-Funktionen oder Steuergeräten.

Die Übermittlung von Teil-Ausführungsgraphen und von Status-Informationen kann kombiniert erfolgen.
Die unter a2) genannte statische Hinterlegung kann z.B. insbesondere für signalorientierte Bus-Systeme wie CAN, Flexray, LIN vorteilhaft sein. Dabei können z.B. für tausende Signale jeweils Sender und Empfänger (jeweils sendendes und empfangendes Steuergerät und/ oder sendende und empfangende Teil-Funktion) hinterlegt sein. Zusätzlich können die charakteristischen Fehlerwerte dieser Signale hinterlegt sein (z.B. 0xFF etc.). Zusätzlich kann hinterlegt sein, für welche dieser charakteristischen Fehlerwerte eine Nutzung der Status-Informationen erfolgen soll, welche Fehlerwerte „relevante“ Fehlerwerte sind und ggf. in welchen Betriebszuständen (z.B. Klemmenstatus, Fahrzeug-Betriebszustand, ...) die Abfrage erfolgen kann. Außerdem können einige oder mehrere dieser Information in einer Fehlermeldung durch die Teil-Funktion an die Beobachtungseinheit enthalten sein.
Eine Teil-Funktion die eine (oder mehrere) andere Teilfunktion nutzt, kann in ihrer Statusinformation oder in Ihrer Fehlerwerten auf dem Bus explizit angeben, dass sie selbst einen (Folge-)Fehler auf Grund dieser anderen bestimmten genutzten Teil-Funktion aufweist.
Die Protokolleinrichtung kann eine Sammlung von Betriebs- oder Fehlerzuständen der verschiedenen Teil-Funktionen vorhalten und ggf. auch permanent aktualisiert halten.
Die Protokolleinrichtung kann hinterlegtes Wissen und/ oder einmal protokollierte („gelernte“) Ausführungsgraphen speichern und in folgenden Betriebs- und Fahrzyklen nutzen. Dabei kann eine Beziehung zwischen den aktuellen Fehlerinformationen und den hinterlegten und/ oder gelernten Abhängigkeitsinformationen gebildet werden. So kann für die verschiedenen Teil-Funktionen

– ein aktueller Fehlerzustand, und/ oder
– ein „Forecast“ erstellt werden, ob eine Funktions-Ausführung erfolgreich sein kann (sie wird z.B. voraussichtlich nicht erfolgreich sein, wenn Teil-Funktionen die im Ausführungsgraphen typischerweise benötigt werden derzeit fehlerhaft sind).

Die aktuelle Fehler-Information kann aktualisiert werden, auch im Hinblick auf das nicht mehr Vorhandensein eines Fehlers. Dies kann z.B. geschehen durch

– Protokollieren einer erfolgreichen Ausführung eines Ausführungsgraphen (auf dem bisher fehlerhafte Teil-Funktionen registriert wurden). Dabei müssen die Ausführungsgraphen unter Umständen nicht identisch sein, sondern sich ggf. nur bzgl. der fraglichen Teil-Funktion, die bisher fehlerhaft war, überlappen.
– Die Teil-Funktionen melden selbständig das Ende eines Fehlerzustandes.
– Die Beobachtungseinheit erkennt auf Basis von Bus-Signalen (z.B. auch zyklischen), dass ein Fehlerzustand nicht mehr vorhanden ist.

Diese Information kann auch erschlossen werden aus der Tatsache, dass mit Entstehen eines Fehlerwerts einer Teil-Funktion plötzlich die diese Teil-Funktion nutzenden anderen Teil-Funktionen einen Fehlerwert am Ausgang senden oder Fehlerbenachrichtigungen an die Beobachtungseinheit ausstellen.
Ein Bordnetz besteht typischerweise aus mehreren heterogenen Bussystemen (Beispiel: CAN, Flexray, LIN, Ethernet/IP). Außerdem können andere zusätzliche Vernetzungstechnologien zum Einsatz kommen, z.B. im Kontext der Backendanbindung (z.B. 3G, LTE, WLAN, ...) oder der Nutzung von CE-Devices (Bluetooth, USB, ...), auf denen ebenfalls jeweils verschiedene Teil-Funktionen partitioniert sein können. Die Bus-Systeme sind typischerweise über ein oder mehrere Gateways miteinander verbunden. Einige Bus-Systeme erlauben differenzierte umfangreiche Fehlerbeschreibungen (z.B. Ethernet/IP), andere auf Grund bestimmter Limitierungen typischerweise eher weniger (z.B. CAN). Die Teil-Funktionen können dabei bus-übergreifend in Verbindung stehen, wobei die Teil-Funktionen je nach Bus-System nach unterschiedlichen der o.g. Verfahren überwacht werden können. Die so möglicherweise heterogen erstellten Informationen werden dann über die Beobachtungseinheiten (z.B. im Gateway, das die Busse verbindet) zusammengefügt, um die Ausführungskette auch über die Grenzen heterogener Bussysteme hinweg verfolgen zu können.
Die Status-Informationen, die in einem Steuergerät bzw. einer Teil-Funktion des Ausführungsgraphen vorliegen, können z.B. Fehler-Situation, Fehler-Ursachen und auch Use-Cases enthalten. Use-Cases können z.B. enthalten, welche Teil-Funktion oder welches Steuergerät die Teil-Funktion aufgerufen hat oder in welchem funktionalen oder fachlichen Zusammenhang die Teil-Funktion andere Teil-Funktionen aufgerufen hat.
Die Schwierigkeit der Ermittlung des Ausführungsgraphen liegt u.a. in den unterschiedlichen und oft sehr ressourcen-beschränkten Kommunikations-Technologien. In heutigen Fahrzeugen sind oft mehrere sehr unterschiedliche Kommunikationstechnologien im Einsatz, so dass für die Fehleranalyse von verketteten Funktionen, die oftmals über mehrere Kommunikations-Technologien hinweg kommunizieren (Beispiel: Sender auf CAN, Empfänger auf Ethernet; oder Sender im Backend über 3G Verbindung, Empfänger auf Flexray), eine heterogene Analyse über mehrere Kommunikation-Technologien und Paradigmen hinweg notwendig ist.
Deshalb kann es vorteilhaft sein, mehrere unterschiedliche, je Technologie-Umfeld jeweils angepasste Verfahren zur Bildung des Ausführungsgraphen und Fehler-Ursachen-Ermittlung miteinander zu kombinieren, wobei die Protokolleinheit(en) die jeweils heterogenen Ansätze zu einem Bild zusammensetzen können und jeweils wieder in geeigneter Form für die jeweiligen Funktionen auf den jeweiligen Bus-Technologien zur Verfügung stellen können.
So kann es vorkommen, dass entweder eine Protokolleinrichtung mehrere der oben genannten Verfahren umsetzt und intern kombiniert (also die unterschiedlich erhaltenen Ausführungsgraphen und unterschiedlich ermittelten Fehler und Fehlerursachen) intern kombiniert und in Bezug zueinander setzt) und/ oder es ist möglich, dass mehrere Beobachtungseinheiten vorhanden sind die untereinander Teil-Informationen austauschen und zusammensetzen.
Ggf. kann gerade ein Fahrzeug-Gateway, das Signale zwischen den Technologien umsetzt und Zugriff auf die meisten Signale hat, zur Umsetzung der Protokolleinrichtung genutzt werden.
Beobachtungseinheit und/ oder Protokolleinrichtung können durch Ihr Wissen über aktuelle Funktions-Fehler ein zentrales Verzeichnis der derzeit fehlerhaften Funktionen erstellen, das für die Funktionen jeweils zugängig ist, so dass diese proaktiv wissen, welche Funktionen derzeit nutzbar sind und welche nicht. Falls Wissen über die möglichen Ausführungsgraphen bekannt ist, können die Funktionen, die die derzeit fehlerhaften Funktionen nutzen, proaktiv über die Fehler informiert werden bzw. diese Information abrufen.
Nicht nur die Bus-Technologien sind unterschiedlich, sondern auch die Kapazität/ Ressourcen der Steuergeräte zur Fehlerbehandlung. Beispielsweise lässt sich bei einer zyklischen CAN-Nachricht, die an mehrere Steuergeräte versendet wird, nur schwer direkt ein Ausführungsgraph ableiten. Durch hinterlegtes Wissen bzgl. der Abhängigkeiten in der Protokolleinrichtung (welche Teilfunktion versendet dieses Signal; welche Teil-Funktionen empfangen dieses Signal) oder hinterlegtes Wissen in den Teil-Funktionen bzgl. ihrer Abhängigkeiten zu Signalen bzw. anderen Teil-Funktionen und Wissen darüber, welche Signal-Werte Fehlerwerte sind, lässt sich dennoch in der zentralen Beobachtungseinheit ein Rückschluss auf Fehlersituationen bilden. Gerade in Verbindung mit einer aktiven Fehler-Meldung durch die sendenden und/ oder empfangenden Teil-Funktionen und/ oder die Abfrage von Statuswerten von den sendenden und/ oder empfangenden Teil-Funktionen kann die Fehlersituation besser erfasst werden.
In anderen Bus-Systemen ist z.B. die Übermittlung aussagekräftiger Fehler-Antworten möglich, so dass in einer Funktions-Ausführungs-Kette die Fehlerinformation jeweils zurückübermittelt werden kann und ggf. weiter „zur Wurzel“ des Ausführungsgraphen übermittelt werden kann. Erfindungsgemäß wird sowohl die Diagnose in der Werkstatt, typischerweise über Fehlerspeichereinträge, als auch die Fehlerdiagnose zur Laufzeit zwischen Teil-Funktionen, die sich gegenseitig nutzen, unterstützt.
Das Registrieren von Signalübermittlungen oder Signal-Aufrufen erfolgt

a) zentral und/ oder
b) die Signalaufrufe werden an eine Beobachtungseinheit übermittelt und jeweils von bestimmten Teil-Funktionen aufaddiert (z.B. speziell im Fehlerfall).

Hierbei setzen sich die funktionalen Abläufe aus Teil-Funktionen gemäß den gerichteten Kanten des Graphs zusammen.
Ein Auslesen einer Statusinformation von Steuergeräten oder von deren Teil-Funktionen gibt einen Hinweis darauf, ob das Steuergerät bzw. die Teil-Funktion spezifikationsgemäß arbeitet oder fehlerhaft ist. Alternativ oder zusätzlich können die Steuergeräte oder Teil-Funktionen aktiv Statusinformationen / Fehler-Situationen an die Protokolleinrichtung melden, die dort gemäß Ausführungsgraph aggregiert werden.
Fehlerwissen kann dabei auf jedem Knoten des Ausführungsgraphen verfügbar sein, und zwar jeweils auf einem bestimmten aggregierten bzw. abstrahierten Niveau.
Es kann dabei Aufgabe der Teil-Funktionen der Knoten oder der Protokolleinrichtung sein, Fehlerinformationen in verschiedenen Graden der Abstraktion bzw. Aggregation bereitzustellen sowie die Fehlerinformation jeweils mit in diesen Komponenten verfügbaren Informationen wie Traces oder Zuständen anzureichern.
Als Bordnetz wird die Gesamtheit aller elektrischen Komponenten in Fahrzeugen angesehen, egal ob aktiv oder passiv. Somit lassen sich alle Komponenten als ein Knoten in einem Graph repräsentieren. Insbesondere wird als Steuergerät auch ein solches Gerät bezeichnet, welches einen Sensor ansteuert.
Teil-Funktionen sind logische Funktionsumfänge, die von den Steuergeräten umgesetzt werden. Ein Steuergerät kann mehrere Teil-Funktionen umsetzen. Funktionen können aus mehreren Teil-Funktionen mehrerer Steuergeräte oder sogar zusätzlich aus Teil-Funktionen über das Fahrzeug hinaus (z.B. des Backends oder von CE-Devices) bestehen.
Generell ist zu berücksichtigen, dass das Problem der Identifizierung der Fehlerursache nicht nur die Handelsorganisation bei der Fahrzeugreparatur betrifft. Auch die Funktionen im Fahrzeug kennen oft die genauen Fehlerursachen einer anderen benötigten Teilfunktion im Fahrzeug nicht. Dies ist erfindungsgemäß möglich.
Kennt der Auslöser der Funktionskette die genaue Ursache für den Fehler, so kann gemäß einem Aspekt der vorliegenden Erfindung differenzierter auf die Fehlersituation reagieren und evtl. sogar durch das Wissen der Fehlerursache die Fehlersituation aufgelöst werden. Es kann z.B. gezielt eine Wiederholung eines Vorgangs oder ein Auflösen eines Konflikts oder Deadlock durchgeführt werden oder es kann trotz des Fehlers fortgefahren werden. Es kann auch der Fehler abgemildert werden und eine abgestimmte, geeignete Degradation durchgeführt werden. In Konsequenz kann das genaue Kennen einer Fehlerursache in einer Fahrzeugfunktion durch die diese nutzenden Funktionen dazu beitragen, dass die Verfügbarkeit von Funktionen erhöht wird. Die zunehmend durch sicherheitsrelevante Funktionen bestimmten Funktionsnetze im Fahrzeug, haben oft die Schwierigkeit, dass Verfügbarkeit von Funktionen und möglichst sichere Abschaltung der Funktionen in Fehlerfällen konkurrierende Ziele sind. Die Erfindung kann durch Bereitstellung präziserer Fehlerinformationen zu einer differenzierteren Fehlerbehandlung beitragen.
Gemäß einem Aspekt der vorliegenden Erfindung weist der Ausführungsgraph Knoten auf, welche signalübermittelnde und/ oder signalempfangende Steuergeräte repräsentieren. Dies hat den Vorteil, dass Sensoren, Signalquellen, Signalsenken und generell alle Komponenten eines Fahrzeugs modelliert und berücksichtigt werden können. Somit lassen sich Signalflüsse bzw. Methodenaufrufe identifizieren und die Komponenten entsprechend abbilden.
Zusätzlich oder alternativ kann der Ausführungsgraph Knoten aufweisen, welche jeweils eine logische Teil-Funktionalität von jeweils einem Steuergerät darstellen, wobei ein Steuergerät mehrere Teil-Funktionalitäten beinhalten kann. Jede Teil-Funktionalität kann mit anderen Teil-Funktionalitäten auf dem gleichen oder einem anderen Steuergerät über Schnittstellen/ Signalübertragungen in Verbindung stehen.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung modelliert der Ausführungsgraph Signalübertragungen als gerichtete und/ oder gewichtete Kanten. Dies hat den Vorteil, dass der Ausführungsgraph derart ausgewertet werden kann, dass alle Knoten ermittelbar sind, welche auf die Funktion eines weiteren Knoten zugreifen. Wird die Funktionalität eines Knotens von mehreren Knoten verwendet, so lassen sich alle Knoten identifizieren, die beispielsweise im Falle eines Ausfalls auf einen Knoten zugreifen. Ferner kann eine Zugriffsfrequenz und/ oder die Fehlerhäufigkeit bzw. Fehlernachhaltigkeit modelliert werden und somit die Kantengewichtung variiert werden. Somit können einzelne Funktionen bezüglich ihrer Bedeutung im Gesamtsystem evaluiert werden. Hier kann eine Gewichtung erhöht werden, falls ein Zugriff auf eine Funktion beziehungsweise auf einen Knoten im Ausführungsgraph erfolgt.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung erfolgt das Registrieren durch kumuliertes Weiterleiten der Signalübertragungen und/ oder durch einzelnes Messen der Signalübertragungen (sozusagen viele kleine Protokolleinrichtungen beziehungsweise Beobachtungseinrichtungen). Dies hat den Vorteil, dass ein kumuliertes Weiterleiten keine ständige Überwachung durch eine zentrale Komponente benötigt. Somit lassen sich vorhandene Bordnetze nachrüsten. Ein Messen der Signalübertragungen durch eine zentrale Einheit kann einen Gewinn an Performanz erzielen. Insbesondere ist es vorteilhaft, dass beide Ansätze des Registrierens kombinierbar sind.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung weist der Teil des Ausführungsgraphs einen Pfad von dem Knoten des fehlerhaften Steuergeräts oder der fehlerhaften Teil-Funktion zu dem oder den Knoten eines Steuergeräts oder einer Teil-Funktion, welcher ein Wurzelelement des Ausführungsgraphs darstellt, auf. Dies hat den Vorteil, dass eine Funktion, welche keine Teil-Funktionen anbietet, sondern diese nur (z.B. per Display) an beispielsweise den Fahrer oder die Fahrerassistenz weitergibt, den gesamten Fehlerpfad bis zur Steuerkomponente die fehlerhaft ist, übermittelt bekommt. Ein Wurzelelement kann beispielsweise manuell bestimmt werden, oder aber auch ein Knoten sein, der nur ausgehende Kanten aufweist. Somit ruft dieser Knoten nur Funktionalität ab und stellt weiteren Knoten keine Dienste bereit. Somit kann das Wurzelelement eine Schnittstelle darstellen, welche einen zusammengesetzten Dienst anderer Knoten einem Endgerät bereitstellt. Die Erfindung kann dabei hierarchisch angewendet werden, in dem jede Teil-Funktion auf dem Ausführungspfad jeweils als Wurzelelement betrachtet werden kann und jeweils die bis zu „sich“ entstandenen Informationen auf aggregiert. Außerdem kann es sich bei dem Ausführungsgraphen um ein „Ausführungs-Netz“ handeln, also keinen streng hierarchischen Graphen, sondern z.B. ein Netz aus Knoten (z.B. mit Zyklen), aufweisend z.B. Regelschleifen. In diesem Falle gibt es Abhängigkeiten aber ggf. kein ausgewiesenes Wurzelelement. Hierbei ist dem Fachmann bekannt, welche graphentheoretische Struktur er am geeignetsten wählt.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung weist der Teil des Ausführungsgraphs alle Knoten auf, deren Kanten auf den Knoten des fehlerhaften Steuergeräts/Teil-Funktion verweisen. Dies hat den Vorteil, dass im Fall eines Ausfalls eines Knotens alle Knoten identifizierbar sind, welche auf dessen Dienste zurückgreifen. Der Graph kann dabei auch Folge-Fehler enthalten oder ggf. auch nur bestimmte Folge-Fehler.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung weist der Ausführungsgraph mehrere Wurzelelemente auf und der Teil des Ausführungsgraphs weist jeweils einen Pfad zu jedem der Wurzelelemente auf. Dies hat den Vorteil, dass ausgehend von einem defekten Steuergerät bzw. Knoten mehrere Knoten identifizierbar sind, welche auf diesen Knoten zugreifen. Insbesondere kann jeweils ein sogenannter Fehlerpfad bereitgestellt werden, der alle Knoten aufweist, die sich zwischen dem oder den Wurzelelementen und dem defekten Knoten befinden.
Die Aufgabe wird auch gelöst durch eine Protokolleinrichtung zur Fehlerdiagnose in einem Bordnetz eines Kraftfahrzeugs, aufweisend eine Beobachtungseinheit eingerichtet zum Erstellen eines Ausführungsgraphs des Bordnetzes mittels Registrierens von Signalaufrufen von Steuergeräten des Bordnetzes sowie eine Schnittstelleneinheit eingerichtet zum Auslesen einer Statusinformation aus jeweils jedem der Steuergeräte und eine Ausgabeeinheit eingerichtet zum Bereitstellen zumindest eines Teils des Ausführungsgraphs an eine Diagnoseeinheit, wobei der Teil des Ausführungsgraphs ein registriertes fehlerhaftes Steuergerät aufweist.
Erfindungsgemäß kann die Schnittstelleneinheit die Statusinformation auch einer entfernt angeordneten Einheit, beispielsweise über eine Luftschnittstelle, übersenden. So kann die Diagnoseeinheit oder generell ein Datenspeicher, welcher mindestens einen Teil des Ausführungsgraphs abspeichert, außerhalb des Fahrzeugs angeordnet werden.
Es gibt beispielhaft zwei Use-Cases der vorliegenden Erfindung, nämlich eine Fehlererkennung in einer Werkstatt oder aber zur Laufzeit des Fahrzeugs sollen die Funktionen untereinander verstehen, warum eine Fehlfunktion auftritt. Somit kann sowohl eine externe Diagnoseeinheit als auch eine interne Diagnoseeinheit Verwendung finden. Extern kann ein spezialisiertes Lesegerät Verwendung finden oder aber auch ein herkömmliches Smartphone mit einer kabelgebundenen oder kabellosen Schnittstelle, welche mit der erfindungsgemäßen Schnittstelleneinheit zu verbinden ist. Auch kann somit eine externes Backend, wie beispielsweise ein Server mitsamt entsprechender Umgebung angebunden werden. Hierzu dient bevorzugt die Schnittstelleneinheit. Diese kann gemäß einem Aspekt der vorliegenden Erfindung auch mit weiteren Geräten kommunizieren, beispielsweise dem Fahrerassistenzsystem.
Die Aufgabe wird auch gelöst durch ein Fahrzeug aufweisend die vorgeschlagene Protokolleinrichtung.
Die Aufgabe wird auch gelöst durch ein Computerprogrammprodukt mit Steuerbefehlen, welche das vorgeschlagene Verfahren implementieren beziehungsweise die vorgeschlagene Protokolleinrichtung betreiben.
Erfindungsgemäß ist es besonders vorteilhaft, dass das Verfahren zum Betreiben der vorgeschlagenen Vorrichtungen und Einheiten verwendet werden kann. Ferner eignen sich die vorgeschlagenen Vorrichtungen und Einrichtungen zur Ausführung des erfindungsgemäßen Verfahrens. Somit implementiert jeweils die Vorrichtung strukturelle Merkmale, welche geeignet sind, das entsprechende Verfahren auszuführen. Die strukturellen Merkmale können jedoch auch als Verfahrensschritte ausgestaltet werden. Auch hält das vorgeschlagene Verfahren Schritte zu Umsetzung der Funktion der strukturellen Merkmale bereit.
Weitere Vorteile, Merkmale und Einzelheiten der Erfindung ergeben sich aus der nachfolgenden Beschreibung, in der unter Bezugnahme auf die Zeichnungen Aspekte der Erfindung im Einzelnen beschrieben sind. Dabei können die in den Ansprüchen und in der Beschreibung erwähnten Merkmale jeweils einzeln für sich oder in beliebiger Kombination erfindungswesentlich sein. Ebenso können die vorstehend genannten und die hier weiter ausgeführten Merkmale je für sich oder zu mehreren in beliebigen Kombinationen Verwendung finden. Funktionsähnliche oder identische Bauteile oder Komponenten sind teilweise mit gleichen Bezugszeichen versehen. In den Figuren zeigen:
1 einen schematischen Ausführungsgraphen zur Fehlerdiagnose in einem Bordnetz gemäß einem Aspekt der vorliegenden Erfindung;
2 einen schematischen Ausführungsgraphen mit einem kumulierten Registrieren gemäß einem Aspekt der vorliegenden Erfindung;
3 einen schematischen Ausführungsgraphen mit einem zentralen, einzelnen Registrieren gemäß einem Aspekt der vorliegenden Erfindung;
4 ein schematisches Blockschaltbild mehrerer Beobachtungseinheiten gemäß einem Aspekt der vorliegenden Erfindung; und
5 ein schematisches Ablaufdiagram zur Fehlerdiagnose in einem Bordnetz gemäß einem Aspekt der vorliegenden Erfindung.
1 zeigt eine schematische Abbildung eines logischen Bordnetzes eines Fahrzeugs. Das logische Bordnetz eines Fahrzeugs besteht aus Funktionen FKT („Services“, „Diensten“, „Funktionen“), ebenso gibt es Funktionen FKT im Backend. Diese Funktionen sind rekursiv aufgeteilt in „Unterfunktionen UFKT“ und verteilt über Steuergeräte im Fahrzeug-Bordnetz bzw. das Backend.
Die Funktionen und Unterfunktionen können genutzt werden um komplexe Kundenfunktionen KKF und Abläufe im Fahrzeug oder im Fahrzeug zusammen mit dem Backend zu realisieren.
Die Erfindung sieht gemäß einem Aspekt vor, ein oder mehrere Beobachtungseinheiten, beziehungsweise Protokolleinrichtungen, im Fahrzeugbordnetz und/ oder Offboard umzusetzen, so dass die Protokolleinrichtung mit möglichst allen Funktionen direkt (oder indirekt über die KKF) in Kontakt stehen kann, und den tatsächlich ausgeführten, logischen Ausführungsgraphen von Funktion FKT und Unterfunktion UFKT im Kontext einer KKF registriert („mitprotokolliert“). Hierdurch entsteht in der/den Protokolleinrichtungen eine Datenstruktur, die den gerichteten Ausführungs-“Graphen“ AFG jeweils einer KKF beschreibt.
Die Protokolleinrichtung registriert nun Fehler, die in den Funktionen FKT oder Unterfunktionen UFKT des AFG auftreten und setzt sie in Beziehung zu einem Element aus dem AFG. Dabei wird die aus Sicht der Funktion FKT oder UFKT jeweils lokal erkennte Fehlersituation oder Fehlerursache dem Element des AFG zugeordnet und registriert. Die lokal erkannten Fehlerursachen sind dabei aus Sicht der Funktionen FKT bzw. Unterfunktionen UFK bewertet und spiegeln jeweils deren Wissen über den Fehler auf Ihrem Abstraktionsgrad wieder. Es entsteht somit im AFG der von der Fehlerursache rückwärts zur Wurzel laufen ein Fehlerpfad.
Auf jedem Element des Pfads wird also ein abstrahiertes Fehlerwissen registriert, zusammen ergibt sich die Kette zurück zum KKF Startpunkt in der Wurzel. Die lokal erkannten Fehlerursachen können dabei mit lokalem Fehlerwissen und Zustandsinformationen ergänzt werden (z.B. Zeitinformation des Fehlerzeitpunktes, lokale Zustandswerten des Steuergeräts auf dem die Funktion FKT oder Unterfunktion UFK partitioniert war oder einem SW-Stacktrace des Steuergeräts etc.). Zusätzlich können globale Zustandswerte (z.B. Bustraces zu den Fehlerzeitpunkten) in der Protokolleinrichtung gesammelt und den lokalen Zustandswerten ergänzt werden.
Die Erfindung sieht in einem Aspekt vor, für möglichste jede KKF eine KKF-ID vorzuhalten, über die die KKF eindeutig identifizierbar ist. Für jede Ausführungs-“Runde“ der KKF wird dynamisch im Fahrzeug (z.B.: von der KKF selbst) ein KKF-HANDLE generiert bzw. hochgezählt. Generell gibt es zwei kombinierbare Möglichkeiten, welche in 2 und 3 dargestellt sind.
2 zeigt eine schematische Abbildung eines logischen Bordnetzes bei dem die Protokolleinrichtung und/ oder die Beobachtungseinheit kumuliert die Steuergeräte mitgeteilt bekommt mitsamt Signalübertragungen, wie zum Beispiel Dienstaufrufe. Dies ist mittels der Pfeile links angedeutet.
Die Funktionen reichen die IDs rekursiv weiter an die Unterfunktionen: Wird die Ausführung einer KKF gestartet, gibt sie die KKF-ID und die KKF-HANDLE-ID bei der Ausführung an die FKT und UFKT weiter und diese wiederum an die FKT und UFKT, die nach diesem im Ausführungsgraphen liegen. Ein solcher Aspekt ist in 2 veranschaulicht.
3 zeigt eine schematische Abbildung eines logischen Bordnetzes bei dem die Protokolleinrichtung und/ oder die Beobachtungseinheit die Steuergeräte selbst mitsamt Signalübertragungen ermittelt. Die Beobachtungseinheit kann als Mittelsmann fungieren, und „mithören“, so dass es nicht notwendig ist, dass die Funktionen sich untereinander die Ids weiterreichen. Ein solcher Aspekt ist in 3 veranschaulicht, in der die Protokolleinrichtung und/ oder die Beobachtungseinheit mittig angeordnet ist. Zusätzlich zum Mithören können Fehler- und Statusinformationen der Funktionen ausgewertet werden (Abfragen, durch Funktion aktiv melden, zwischen Funktionen ausgetauschte Status-Informationen mithören).
Auch FKT und UFKT können ID und Handle-ID haben. Es ergibt sich eine Kette: (IDa: Handle-IDa).(IDb: Handle-ID b). ... .(IDz: Handle-IDz) bzw. ein entsprechender Graph, Die Protokolleinrichtung registriert durch „Mitlauschen“ selbstständig Signale im Bordnetz, z.B. solche, die aus „Trigger“ bzw. „Aufruf“ bzw. Aufforderung zur Funktionsstart oder zur Zustandsänderung einer FKT oder UFKT gewertet werden. Die Protokolleinrichtung empfängt Fehlerwerte, die die FKT/UFKT aktiv an Protokolleinrichtung senden oder fragt diese Fehlerwerte explizit ab.
Mögliche Fehlerreaktionen sind dann gemäß einem Aspekt der vorliegenden Erfindung wie folgt durchführbar. In den beschriebenen Szenarien ist die Fehlerkette im Ausführungsgraph bekannt, nämlich durch:

a) hierarchisches Weiterreichen;
b) Mitlauschen in der Protokolleinrichtung;
c) aktives Nachfragen durch die Protokolleinrichtung; oder
d) jeweils aktives Benachrichtigen der Protokolleinrichtung durch die jeweils lokalen Teil-Funktionen. Im Rahmen der Benachrichtigung kann die Fehlerursache (z.B. Fehlerhaftes Signal xyz) und/ oder die fehlerhafte Quelle/Vorgänger-Teilfunktion genannt werden. Letztere kann auch über hinterlegtes Abhängigkeitswissen in der Protokolleinrichtung erschlossen werden (z.B. Teilfunktion x ist über Signal a von Teilfunktion y abhängig. Wenn nun Teilfunktion y einen Fehler meldet bzgl. Signal a ist vermutlich Teilfunktion y Schuld.)

Der Protokolleinrichtung stellt die Information über erkannten Ausführungsgraph bzw. die dort aufgetretenen Fehler allen Funktionen zur Verfügung oder ggf. auch nur den im jeweiligen Ausführungsgraph involvierten. Die Funktionen können nun mit der Information des Fehlerursprungs („WO“; „Welche Teilfunktion“) und der Fehlerursache in diesem Fehlerursprung („WAS“, z.B.: FKT konnte gerade nicht ausgeführt werden, weil die Komponente durch andere Funktionsausführung noch beschäftigt ist) und die Fehlerpropagation (wie hat sich der Fehler im Graph „darüber“ ausgewirkt) nutzen. Die Protokolleinrichtung kann aktuelle und/ oder historische Fehler-Information auf Anfrage an die Funktionen bereitstellen, oder z.B. auch an alle oder die betroffenen Funktionen aktiv verteilten. Welche Funktionen betroffen sind oder sein können kann über aktuelle und/ oder gelernte/ gespeicherte und/ oder hinterlegte Ausführungsgraphen und Abhängigkeitsinformationen ermittelt werden.
Hierdurch kann die Verfügbarkeit von Funktionen erhöht werden, da die vom der Fehlerauswirkung betroffene Funktion nun differenzierter entscheiden kann, wie sie auf den Fehler reagiert. Somit kann beispielsweise in einem sicherheitsrelevanten System ggf. eine „Komplettabschaltung“ verhindert werden und durch eine gezieltere Fehlerreaktionsmaßnahme, z.B. Wiederholen, eine Zeitdauer warten, abschalten, trotz Fehler weitermachen o.ä., ersetzt werden, die die Funktion ggf. für den Kunden noch nutzbar macht.
Außerdem kann es sein, dass der Fehler wegen einer „unwichtigeren“ Tatsache auftritt, so dass eine Fehlerbehandlung wie beispielsweise Override, Übersteuern oder „trotz Fehler Funktion nicht beenden“ durchgeführt werden kann.
Eine Markierung oder Klassifizierung der Fehler im Sinne von „kritisch“/ “unkritisch“, „temporär“/ “permanent“, oder fachlich wie (Nachrichtenfehler, Sensorfehler, Logikfehler, Software-Fehler, Hardware-Fehler, unklarer Fehler, unwichtiger Fehler, Folge-Fehler auf Grund Fehler in benötigter anderer Teil-Funktion), kann helfen für dritte Funktionen den Fehler leichter einschätzbar zu machen und einfacher zu reagieren.
Die Protokolleinrichtung kann bestimmte Fehler, z.B. permanente Ausfälle, bestimmter Teilfunktionen im Ausführungsgraph registrieren, zusammenzufassen, abstrahieren, kategorisieren und an alle Funktionen, die sich für diese Teilfunktion interessieren beziehungsweise darauf zurückgreifen, diese Fehler und die Ursache kommunizieren, noch bevor eine Funktion überhaupt versucht die fehlerbehaftete Teilfunktion auszuführen. Somit kann proaktiv eine alternative Ausführung oder Reaktion gefunden werden. Die Bereitstellung des Fehlers und der Fehlerursachen kann auch an im Backend partitionierte Teil-Funktionen erfolgen sowie umgekehrt Fehler und Ursachen von Teil-Funktionen im Backend können über die Protokolleinrichtung im Fahrzeug bereitgestellt werden.
Derartige Fehler-Informationen können je nach Interessent einerseits sehr detailliert (z.B. mit ergänzenden Status-Informationen aus dem Bordnetz, z.B. Bus-Traces) gespeichert/ zur Verfügung gestellt werden und/ oder andererseits auch stark abstrahiert und vereinfacht/ verkleinert an Funktionen bereitgestellt werden. Beispiele für eine abstrahierte Bereitstellung sind:

– Fehler „Ungültige Eingangsdaten: Fehler Liste erkannter vorausfahrender Fahrzeuge im Video“ aus der genutzten Teil-Funktion „Erkennung Fahrzeuge in Video“, wegen Fehler „keine Videodaten“ in genutzter Teil-Funktion „Video-Rohdatenverarbeitung“, wegen Fehler „Video-Sensor reagiert nicht“ bzgl. Sensor „Video-Sensor“
– Fehler „Ungültige Eingangsdaten Fusionierte Video-Objekte“, Ursache Sensorfehler in genutzter Teil-Funktion „Erkennung Fahrzeuge in Video“ mit Ursache Sensor-Fehler „Video-Sensor“
– Sensorfehler „Video-Sensor“

Die Protokolleinrichtung kann außerdem entsprechende Maßnahmen ergreifen, um den Fehler noch besser zu dokumentieren und dadurch greifbar zu machen, wie z. B. einen Trace aufzeichnen, Zustände merken, Detaildaten von verschiedenen Funktionen abfragen und merken etc. In komplexen verteilten Systemen bietet der Ansatz erhöhte Verfolgbarkeit von Fehlern im System von der Fehlerursache bis zur Fehlerauswirkung gerade auch dann, wenn ein Fehler nicht innerhalb eines Steuergeräts lokal, sondern in einem komplexen verteilten Verbund auftritt.
In Konsequenz kann das genaue Kennen einer Fehlerursache und Fehlerpropagation in einer Fahrzeugfunktion durch die diese nutzenden Funktionen dazu führen, dass die Verfügbarkeit von Funktionen erhöht wird. Die zunehmend durch sicherheitsrelevante Funktionen bestimmten Funktionsnetze im Fahrzeug, haben oft die Schwierigkeit, dass Verfügbarkeit und frühzeitige Abschaltung sicherheitsrelevanter Systeme konkurrierende Ziele sind. Je höher die Sicherheitsrelevanz und z.B. auch die Abhängigkeiten der Funktion, desto schwieriger oft die Verfügbarkeit der Funktion.
Die Ausgabeeinheit ist gemäß einem Aspekt der vorliegenden Erfindung eingerichtet zum Bereitstellen zumindest eines Teils des Ausführungsgraphs mit den jeweiligen Fehler und der Fehler-Ursachen je Knoten des Ausführungsgraphs an eine Diagnoseeinheit und/ oder an andere interessierte Teil-Funktionen des Fahrzeugs bzw. mit dem Fahrzeug verbundene Systeme (z.B.: Backend, CE-Devices), wobei der Teil des Ausführungsgraphs ein registriertes fehlerhaftes Steuergerät und/ oder eine Teil-Funktion aufweist
4 zeigt ein Netzwerk aus Beobachtungseinheiten BE1, BE2 und BE3. Im System kann es mehrere Beobachtungseinheiten BE1, BE2 und BE3 bzw. BE-Teile geben, die die ggf. nur in einem Teilnetz verfügbaren Teil-Informationen austauschen bzw. kombinieren, so dass ein Gesamtbild und/ oder ein Gesamtgraph entsteht.
Ein oder mehrere Beobachtungseinheiten können dabei auch außerhalb des Fahrzeugs in Systemen partitioniert sein, die mit dem Fahrzeug funktional in Verbindung stehen (z.B. Teil-Funktionen im Backend oder Teil-Funktionen in CE-Devices/ Apps).
Im System können mehrere Protokolleinrichtungen BE1, BE2 und BE3 nach Variante 1 (siehe 2) oder Variante 2 (siehe 3) oder BEs sein, die beide Eigenschaften kombinieren. Ebenso kann ein Teil eines Ausführungsgraphen über Variante 1 und ein anderer Teil über Variante 2 identifiziert werden. Dies besonders dann, wenn auf dem AFG Teilfunktionen sitzen, die das explizite rekursive weiterreichen von IDs nicht unterstützen.
5 zeigt ein Verfahren zur Fehlerdiagnose in einem Bordnetz eines Kraftfahrzeugs, aufweisend ein Erstellen 100 eines Ausführungsgraphs des Bordnetzes mittels Registrierens von Signalaufrufen von Steuergeräten des Bordnetzes und ein Auslesen 101 einer Statusinformation aus jeweils jedem der Steuergeräte sowie ein Bereitstellen 102 zumindest eines Teils des Ausführungsgraphs an eine Diagnoseeinheit, wobei der Teil des Ausführungsgraphs ein registriertes fehlerhaftes Steuergerät aufweist.
Generell kann es bereits vorab bekannt sein, welche Komponente in dem Fahrzeug potentiell welche Funktionen aufruft und gegebenenfalls mitsamt der Signatur. So sind die Empfänger beziehungsweise Sender von Signalaufrufen beispielsweise festverdrahtet. Auch diese Information kann bei der Erstellung eines Ausführungsgraphs erfindungsgemäß berücksichtigt werden.
So sind gemäß einem Aspekt der vorliegenden Erfindung die Funktionen beziehungsweise Teilfunktionen statisch hinterlegt bzw. durch die konkrete strukturelle Ausgestaltung implizit gegeben. Ferner kann generell ein Auslesen einer Statusinformation erfolgen, oder aber auch ein aktives Veranlassen einer Übermittlung von Statusinformation.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 19836126 A1 [0002]
DE 102008044405 A1 [0003]
DE 19700353 A1 [0004]

Claims

Verfahren zur Fehlerdiagnose in einem Bordnetz eines Kraftfahrzeugs, gekennzeichnet durch die Schritte: – Erstellen (100) eines Ausführungsgraphs des Bordnetzes durch Registrieren von Signalaufrufen von miteinander vernetzten Steuergeräten des Bordnetzes; – Auslesen (101) einer Statusinformation aus jeweils jedem der Steuergeräte; und – Bereitstellen (102) zumindest eines Teils des Ausführungsgraphs an eine Diagnoseeinheit, wobei der Teil des Ausführungsgraphs ein registriertes fehlerhaftes Steuergerät aufweist.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Ausführungsgraph Knoten aufweist, welche signalübermittelnde und/ oder signalempfangende Steuergeräte repräsentieren.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Ausführungsgraph Signalübertragungen als gerichtete und/ oder gewichtete Kanten modelliert.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Registrieren (100) durch kumuliertes Weiterleiten der Signalübertragungen und/ oder durch einzelnes Messen der Signalübertragungen erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Teil des Ausführungsgraphs einen Pfad von dem Knoten des fehlerhaften Steuergeräts zu dem Knoten eines Steuergeräts, welcher ein Wurzelelement des Ausführungsgraphs darstellt, aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Teil des Ausführungsgraphs alle Knoten aufweist, deren Kanten auf den Knoten des fehlerhaften Steuergeräts verweisen.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ausführungsgraph mehrere Wurzelelemente aufweist und der Teil des Ausführungsgraphs jeweils einen Pfad zu jedem der Wurzelelemente aufweist.
Protokolleinrichtung zur Fehlerdiagnose in einem Bordnetz eines Kraftfahrzeugs, gekennzeichnet durch: – eine Beobachtungseinheit (BE) eingerichtet zum Erstellen eines Ausführungsgraphs des Bordnetzes durch Registrieren von Signalaufrufen von miteinander vernetzten Steuergeräten des Bordnetzes; – eine Schnittstelleneinheit eingerichtet zum Auslesen einer Statusinformation aus jeweils jedem der Steuergeräte; und – eine Ausgabeeinheit eingerichtet zum Bereitstellen zumindest eines Teils des Ausführungsgraphs an eine Diagnoseeinheit, wobei der Teil des Ausführungsgraphs ein registriertes fehlerhaftes Steuergerät aufweist.
Fahrzeug aufweisend eine Protokolleinrichtung nach Anspruch 8.
Computerprogrammprodukt mit Steuerbefehlen, welche das Verfahren nach einem der Ansprüche 1 bis 7 implementieren.