Diagnosevorrichtungen in einem Fahrzeug mit Diagnoseframework für Diagnosemodule

Abstract

 Die Erfindung betrifft eine Vorrichtung in einem Fahrzeug für eine Diagnose durch einen Fahrzeug-Datenbus (15-18; 35) vernetzter Fahrzeugsysteme (2-14; 36), umfassend eine Diagnoseeinheit (32; 40), die eine Schnittstelle (45) für ein Austauschen von Informationen über den Fahrzeug-Datenbus umfasst, wobei auf die Schnittstelle (45) ein Diagnoseframework (21; 33; 44) aufsetzt, das eine Anwendungsprogramm-Schnittstelle (API) für Diagnosemodule (22-26; 34; 52-58) bereitstellt, die zum Ausführen der fahrzeuginternen Diagnose der einzelnen Fahrzeugsysteme (2-14; 36) ausgestaltet sind, wobei mehrere Diagnosemodule (22-26; 34; 52-58) zeitgleich parallel auf dem Diagnoseframework (21; 33; 44) ausgeführt werden und das Diagnoseframework (21; 33; 44) einen Zugriff der Diagnosemodule (22-26; 34; 52-58) auf die Fahrzeugsysteme (2-14; 36) koordiniert.

Beschreibung

[0001] Die Erfindung betrifft eine Vorrichtung in einem Fahrzeug für eine Diagnose durch einen Fahrzeug-Datenbus vernetzter Fahrzeugsysteme, umfassend eine Diagnoseeinheit, die eine Schnittstelle für ein Austauschen von Informationen über den Fahrzeug-Datenbus mit den vernetzten Fahrzeugsystemen umfasst.

[0002] In Fahrzeugen sind einzelne Fahrzeugsysteme, die vorzugsweise Steuergeräte umfassen, durch einen Fahrzeug-Datenbus miteinander vernetzt. Um in dem Fahrzeug eine Diagnose der Fahrzeugsysteme ausführen zu können, ist im Stand der Technik vorgesehen, dass die einzelnen Fahrzeugsysteme jeweils eine Diagnoseeinheit umfassen, die in das jeweilige Steuergerät des Fahrzeugsystems integriert ist. Die Diagnose der einzelnen Fahrzeugsysteme wird von den einzelnen Diagnoseeinheiten in den Fahrzeugsystemen durchgeführt. Dabei ermittelte Fehler werden in einem Fehlerspeicher in den einzelnen Fahrzeugsystemen abgelegt. Über ein fahrzeugexternes Diagnose- und Testgerät, welches mit dem Fahrzeug-Datenbus verknüpft wird, können die einzelnen Diagnoseeinheiten bzw. Fehlerspeicher abgefragt werden. Eine umfassende Analyse des Fahrzeugs als Ganzes ist durch diese Vorgehensweise erschwert. Ferner werden in den einzelnen Diagnoseeinheiten der Fahrzeugsysteme häufig ähnliche Diagnosekapazitäten vorgehalten. Eine solche Diagnosevorrichtung ist beispielsweise in der DE 102 54 393 A1 beschrieben.

[0003] Aus der DE 101 15 042 A1 ist eine Vorrichtung für eine Funktionsprüfung elektrischer Komponenten bei der Produktion von Kraftfahrzeugen bekannt. Ein Diagnosesteuergerät wird mit Daten und Signalleitungen eines Kabelbaums verbunden und führt während des Produktionsablaufs Funktionsprüfungen der bereits verbauten Komponenten durch. Die erhaltenen Diagnoseergebnisse werden drahtlos übertragen und zur Ortung des Kraftfahrzeugs während der Produktion verwendet. Das hierbei eingesetzte Diagnosegerät kann in ein Steuergerät integriert sein, das im Betrieb des Fahrzeugs später ebenfalls Überprüfungsfunktionen wahrnimmt. Bei der bekannten Vorrichtung ist vorgesehen, dass einzelne Prüfabschnitte nacheinander ausgeführt werden, um einzelne Komponenten des produzierten Fahrzeugs zu überprüfen. Zwar ist vorgesehen, dass das Prüfprogramm, das als Software ausgebildet ist, ersetzt werden kann, ein zeitgleiches Ausführen mehrerer Prüfvorgänge ist jedoch nicht vorgesehen. Somit ist eine komplexe Diagnose insbesondere dann erschwert, wenn mehrere Fahrzeugkomponenten parallel überprüft werden sollen.

[0004] Der Erfindung liegt die technische Aufgabe zugrunde, eine Vorrichtung für eine Diagnose durch einen Fahrzeug-Datenbus vernetzter Fahrzeugsysteme zu schaffen, bei dem eine zeitgleiche parallele Diagnose mehrerer Fahrzeugsysteme möglich ist und eine Erweiterbarkeit und Anpassung der Diagnosefähigkeiten bei einer Modifikation des Fahrzeugs nach der ursprünglichen Produktion einfach möglich ist.

[0005] Dieses technische Problem wird erfindungsgemäß durch einen Gegenstand mit den Merkmalen des Patentanspruchs 1 gelöst, wobei vorgesehen ist, dass auf die Schnittstelle ein Diagnoseframework aufsetzt, das eine Anwendungsprogramm-Schnittstelle (API) für Diagnosemodule bereitstellt, die zum Ausführen der fahrzeuginternen Diagnose der einzelnen Fahrzeugsysteme ausgestaltet sind, wobei mehrere Diagnosemodule zeitgleich parallel auf dem Diagnoseframework ausgeführt werden und das Diagnoseframework einen Zugriff der Diagnosemodule auf die Fahrzeugsysteme koordiniert. Hierdurch wird es möglich, mehrere Fahrzeugsysteme parallel zu analysieren. Bei der zunehmenden Vernetzung von Fahrzeugsystemen und einer starken Zunahme der elektrischen und elektronischen Fahrzeugsysteme ist eine schnelle und zeitnahe Diagnose mehrerer Fahrzeugsysteme notwendig. Indem der Zugriff auf die Fahrzeugsysteme durch das Diagnoseframework koordiniert wird, kann die Anzahl der Zugriffe auf den Fahrzeug-Datenbus minimiert werden.

[0006] Als besonders vorteilhaft hat es sich herausgestellt, einzelne übermittelte Daten der Fahrzeugsysteme zentral im Diagnoseframework vorzuhalten, da diese häufig von mehreren Diagnosemodulen benötigt werden. Daher ist vorteilhafterweise vorgesehen, dass das Diagnoseframework einen Teil der von den Fahrzeugsystemen übermittelten Daten in einem Speicherbereich vorhält, um die Anzahl der Zugriffe der Diagnosemodule auf die Fahrzeugsysteme zu verringern.

[0007] Als besonders vorteilhaft hat sich eine Ausführungsform erwiesen, bei der das Diagnoseframework einen zentralen Fehlerspeicher umfasst, in dem die Fehlerereignisse der vernetzten Fahrzeugsysteme gemeinsam abgelegt sind. Bei einer Diagnose, bei der mehrere Einzelsysteme gemeinsam diagnostiziert werden, kann somit auf einfache Weise ein Überblick über aufgetretene Fehlerereignisse erhalten werden.

[0008] In modernen Fahrzeugen werden die bei der fahrzeuginternen Diagnose ermittelten Ergebnisse ebenfalls für die Wartung und Reparatur der Fahrzeuge verwendet. Es ist daher üblich, fahrzeugexterne Testgeräte mit dem Fahrzeug zu koppeln, um die internen Diagnoseergebnisse auszulesen bzw. gezielt Diagnoseschritte an den Fahrzeugsystemen vornehmen zu lassen und/oder auszuführen. Eine bevorzugte Ausführungsform sieht daher vor, dass die Diagnoseeinheit über den Fahrzeug-Datenbus oder über eine weitere Schnittstelle mit einem fahrzeugexternen Testgerät verknüpfbar ist, wobei ein Datenaustausch zwischen dem fahrzeugexternen Testgerät und den Diagnosemodulen oder den Fahrzeugsystemen über das Diagnoseframework erfolgt. Dies bietet den Vorteil, dass das Diagnoseframework eine einheitliche Schnittstelle für einen Zugriff eines externen Testgeräts bereitstellen kann. Somit können unterschiedliche Fahrzeuge mit ein und demselben externen Testgerät zusammenwirken. Es ist lediglich erforderlich, die einzelnen Diagnoseframeworks der unterschiedlichen Fahrzeuge an die darin verbauten Fahrzeugsysteme anzupassen. Die Diagnosemodule, die in die Anwendungsprogramm-Schnittstelle des Diagnoseframeworks eingepasst sind, können ebenfalls universell verwendet werden. Bei einer externen Diagnose wird durch das vorgeschlagene Vorgehen erreicht, dass die bereits durch die fahrzeuginterne Diagnose ermittelten Ergebnisse besonders einfach und schnell erfasst werden können. Ist beispielsweise ein Speicherbereich für die gemeinsame Ablage der Fehlerereignisse der Fahrzeugsysteme vorgesehen, so können diese Fehlerereignisse schnell zu dem externen Testgerät über das Diagnoseframework übertragen werden, ohne dass Zugriffe über den Fahrzeug-Datenbus auf die einzelnen Fahrzeugsysteme notwendig sind. Hierdurch wird die Fahrzeugdiagnose mit einem externen Testgerät beschleunigt.

[0009] Das Diagnoseframework ist vorteilhafterweise so ausgestaltet, dass den Diagnosemodulen Diagnosefunktionen und/oder Diagnoseroutinen und/oder Speicher und/oder Rechenkapazität zentral bereitgestellt werden. Hierbei können Diagnoseroutinen oder auch Speicherbereiche von mehreren Diagnosemodulen gemeinsam genutzt werden. Hierdurch wird die benötigte Speicher- und Rechenkapazität im Fahrzeug verringert. Die einzelnen Fahrzeugsysteme müssen nicht mehr dafür ausgelegt sein, selbstständig Diagnosefunktionen ausführen zu können. Hierdurch werden die einzelnen Fahrzeugsysteme einfacher und billiger. Das vorgeschlagene Vorgehen zeichnet sich ferner dadurch aus, dass nach einer Fertigstellung des Fahrzeugs die Diagnosefunktionalität erweitert und/oder verändert werden kann. Hierbei ist es nicht erforderlich, die einzelnen Fahrzeugsysteme zu modifizieren, was sehr aufwendig ist. Es ist vielmehr ausreichend, einzelne oder alle Diagnosemodule zu modifizieren, auszutauschen oder ein neues oder mehrere neue Diagnosemodule der Diagnoseeinheit zuzufügen. Insbesondere bei einer hohen Vernetzung der Fahrzeugsysteme, die gemeinsam Fahrzeugfunktionen zur Verfügung stellen, ist dies vorteilhaft oder erforderlich. Eine funktionsorientierte Diagnose ist in der Regel mit Diagnosemodulen, die in die einzelnen Fahrzeugsysteme integriert sind, nur unbefriedigend oder gar nicht möglich. Insbesondere bei einer funktionsorientierten Diagnose werden viele Daten und Informationen der einzelnen Fahrzeugsysteme von mehreren Funktionsdiagnosen benötigt. Indem die Diagnosemodule in das Diagnoseframework eingebettet sind, wird erreicht, dass das Diagnoseframework diese Daten zentral vorhalten kann, so dass die Anzahl der Zugriffe auf die Fahrzeugsysteme und eine Belastung des Fahrzeug-Datenbusses deutlich verringert wird.

[0010] Die Fahrzeugsysteme umfassen vorzugsweise jeweils mindestens ein Steuergerät. Bei einer besonders bevorzugten Ausführungsform ist die Diagnoseeinheit in ein Steuergerät des Fahrzeugs integriert, vorzugsweise in ein zentrales Multifunktionsanzeigebediensystem.

[0011] Bei einer besonders bevorzugten Ausführungsform ist der Fahrzeug-Datenbus ein CAN-Bus und mindestens eines der Diagnosemodule als CAN-Snap-Modul ausgestaltet, um vorwählbare CAN-Bus-Informationen zu protokollieren. Ein CAN-Snap-Modul ist ein Diagnosemodul, das in der Lage ist, vorausgewählte Daten, die über den Fahrzeug-Datenbus übermittelt werden, zu protokollieren. Hierbei können Vorgaben gemacht werden, welche Daten protokolliert werden sollen. Die protokollierten Daten können in einem Speicher in dem Diagnoseframework abgelegt werden, um für eine spätere Offline-Analyse zur Verfügung zu stehen. Daher ist bei einer bevorzugten Ausführungsform ein Speicher in dem Diagnoseframework vorgesehen, um darin die protokollierten CAN-Bus-Informationen abzulegen.

[0012] Eine Weiterbildung der Erfindung sieht vor, dass das mindestens eine als CAN-Snap-Modul ausgestaltete Diagnosemodul und/oder mindestens ein weiteres der Diagnosemodule ausgestaltet sind, die protokollierten CAN-Bus-Informationen hinsichtlich eines Schlechtverhaltens oder einer Abweichung von einem Gutverhalten in Echtzeit zu analysieren. Hierdurch können Fehlerereignisse detektiert werden, die vorher festgelegt sind. Zur Ermittlung von Fehlerursachen können so gezielt, insbesondere bei komplexen Vorgängen, automatisiert Funktionsabläufe überwacht werden.

[0013] Besonders vorteilhaft ist es daher, bei einer Ausführungsform vorzusehen, dass mindestens eines der Diagnosemodule ausgestaltet ist, bei einem Feststellen eines Fehlerereignisses das CAN-Snap-Modul entsprechend des Fehlerereignisses zu konfigurieren, um die protokollierten CAN-Bus-Informationen und/oder einen einstellbaren Zeitraum für das Protokollieren festzulegen. So werden für eine Offline-Diagnose mit einem fahrzeugexternen Testgerät ausreichend Informationen gesammelt. Hierdurch werden im Betrieb auftretende komplexe Fehlerzusammenhänge für Werkstattpersonal nachvollziehbar und diagnostizierbar.

[0014] Die Erfindung wird nachfolgend anhand bevorzugter Ausführungsbeispiele unter Bezugnahme auf Figuren näher erläutert. Hierbei zeigen:

Fig. 1

eine schematische Ansicht eines Fahrzeugs mit einer Ausführungsform einer Diagnoseeinheit;

Fig. 2

eine schematische Darstellung zur Erläuterung der Fahrzeugdiagnose mit einer Diagnoseeinheit, die ein Diagnoseframework umfasst;

Fig. 3

eine weitere schematische Ansicht einer Vorrichtung zur Diagnose vernetzter Fahrzeugsysteme; und

Fig. 4

eine Darstellung unterschiedlicher Messinformationen, aufgetragen gegen die Zeit, zur Erläuterung des Protokollierens von Signalen mittels eines CAN-Snap-Moduls.

[0015] In Fig. 1 ist schematisch ein Fahrzeug 1 dargestellt. Das Fahrzeug 1 umfasst mehrere Fahrzeugsysteme 2-14. Diese Fahrzeugsysteme 2-14 sind als Motorsteuergerät 2, Bremsensteuergerät 3, Getriebesteuergerät 4, Komfortsteuergerät 5, Bordnetzsteuergerät 6, Türsteuergerät 7, Radio 8, Navigationssteuergerät 9, Telematiksteuergerät 10, Schalttafel 11, weitere Steuergeräte 12, 13 und als Gateway 14 ausgestaltet. Mit dem Gateway 14 sind mehrere Fahrzeugdatenbusse 15-19 verknüpft. Die Fahrzeug-Datenbusse 15-19 sind als CAN-Antriebs-Datenbus 15, CAN-Komfort-Datenbus 16, CAN-Infotainment-Datenbus 17, CAN-Kombi-Datenbus 18 und als CAN-Diagnose-Datenbus 19 ausgestaltet. Mit dem CAN-Antriebs-Datenbus 15 sind das Motorsteuergerät 2, das Bremsensteuergerät 3, das Getriebesteuergerät 4 und das weitere Steuergerät 12 verbunden. Mit dem CAN-Komfort-Datenbus 16 sind das Komfortsteuergerät 5, das Bordnetzsteuergerät 6, das Türsteuergerät 7 und das weitere Steuergerät 13 verbunden. Mit dem CAN-Infotainment-Datenbus 17 sind das Radio 8, das Navigationssteuergerät 9 und das Telematiksteuergerät 10 verbunden. Mit dem CAN-Kombi-Datenbus 18 ist die Schalttafel 11 verbunden, die mehrere Kombinationsbedienelemente und Anzeigegeräte umfasst. Der CAN-Diagnose-Datenbus 19 ist mit einem fahrzeugexternen Testgerät 20 verbunden. In dem Gateway 14 ist ein Diagnoseframework 21 vorgesehen. Zwischen dem Diagnoseframework 21 und den einzelnen Fahrzeug-Datenbussen 15-19 sind eine oder mehrere Schnittstellen in dem Gateway 14 vorgesehen (nicht dargestellt). In das Diagnoseframework 21 sind einzelne Diagnosemodule 22-26 eingebettet bzw. auf das Diagnoseframework 21 aufgesetzt. Die Diagnosemodule 22-26 umfassen ein Zentraldiagnosemodul 22, ein Systemdiagnosemodul 23, ein CAN-Snap-Diagnosemodul 24, ein Telemetriedatenkoordinierungsdiagnosemodul 25 und ein Prüfmodul 26. Diese Diagnosemodule 22-26 führen die fahrzeuginterne Diagnose der Fahrzeugsysteme 2-14 aus. Dies bedeutet, die einzelnen Fahrzeugsysteme 2-14 umfassen keine selbstständigen Diagnosemodule. Die Diagnose wird zentral von den Diagnosemodulen 22-26 in dem Diagnoseframework 21 ausgeführt. Hierdurch wird die Anzahl der Zugriffe, die mittels der Linien 27 angedeutet sind, auf die Fahrzeugsysteme 2-13 von ihrer Anzahl her deutlich reduziert. Eine von dem fahrzeugexternen Testgerät 20 ausgeführte Diagnose wird über das Diagnoseframework ausgeführt, wie mittels der Linie 28 angedeutet ist. Die gepunktet dargestellten Linien 29, die klassische Diagnosezugriffe bei einer Ausführungsform nach dem Stand der Technik andeutet, sind bei dem Fahrzeug 1 nicht vorgesehen.

[0016] In Fig. 2 ist eine weitere schematische Darstellung eines Fahrzeugs 30 mit einem fahrzeugexternen Testgerät 31 dargestellt. Das Fahrzeug 30 umfasst eine als Gateway ausgestaltete Diagnoseeinheit 32. Die Diagnoseeinheit 32 umfasst ein Diagnoseframework 33, in das Diagnosemodule 34 integriert sind. Mit der Diagnoseeinheit sind über einen Fahrzeug-Datenbus 35 als Steuergeräte ausgebildete Fahrzeugsysteme 36 vernetzt. Die Diagnoseeinheit 32 und das fahrzeugexterne Testgerät 31 sind über einen weiteren Fahrzeugdatenbus 37 miteinander vernetzt. Die Fahrzeugsysteme 36 umfassen keine Diagnosemodule. Die Diagnose des Fahrzeugs 30 wird zentral von den Diagnosemodulen 34 in dem Diagnoseframework 33 ausgeführt. Einzelne externe Diagnosemodule 38 des fahrzeugexternen Testgeräts 31 greifen über eine Diagnoseapplikation 39 auf das zentrale Diagnoseframework 33 bzw. die darin enthaltenen Diagnosemodule 34 zu. Ein direkter Zugriff von Diagnosemodulen des fahrzeugexternen Testgeräts 31 auf die Fahrzeugsysteme 36 ist nicht vorgesehen.

[0017] In Fig. 3 ist eine weitere Ausführungsform einer als Steuergerät ausgestalteten Diagnoseeinheit 40 dargestellt. Die Diagnoseeinheit 40 umfasst einen Speicher 41 sowie einen Betriebssystemsoftwarekern 42. Auf den Betriebssystemsoftwarekern 42 setzt eine Betriebssystem-Anwendungsprogramm-Schnittstelle 43 (API) auf. Auf die Betriebssystem-Anwendungsprogramm-Schnittstelle 43 setzt wiederum ein Diagnoseframework 44 auf, das eine Anwendungsprogramm-Schnittstelle darstellt. Das Diagnoseframework 44 nutzt Teile des Speichers 41. Diese dem Diagnoseframework 44 zugewiesenen Bereiche des Speichers 41 werden als Speicher des Diagnoseframeworks 44 betrachtet. Das Diagnoseframework 44 setzt ferner auf einer Schnittstelle 45 auf. Die Schnittstelle 45 umfasst eine CAN-Anwendungsprogramm-Schnittstelle 46, einen CAN-Softwarekern 47 sowie einzelne physikalische CAN-Schnittstellen 48. Auf den CAN-Softwarekern 47 setzt ferner ein Bandwidth-Allocation-Protocol 49 sowie ein ISO-Transportprotokoll 50 auf, auf denen wiederum ein KWP-2000-Protokoll 51 aufsetzt. Auf das Diagnoseframework 44 setzen Diagnosemodule 52-58 auf. Die Diagnosemodule umfassen ein Diagnosemodul 52, das eine Fehlerliste erstellt, ein CAN-Snap-Diagnosemodul 53, ein Prüfmodul 54, ein Systemdiagnosemodul 55, ein Telemetriedatenkoordinierungsdiagnosemodul 56, ein funktionsorientiertes Diagnosemodul 57 sowie weitere Diagnosemodule 58. Über eine CAN-Datenbus-Vernetzung 59 sind die Fahrzeugsysteme mit der Diagnoseeinheit 40 verknüpft. Hierüber ist ebenfalls über einen Diagnosestecker 60 ein fahrzeugexternes Testgerät 61 mit der Diagnoseeinheit 40 verbunden, wobei ein Datenaustausch mittels des KWP-2000-Protokolls erfolgt. Das fahrzeugexterne Testgerät 61 umfasst einen Systemkonfigurationskoordinator 62, der auf einem Kommunikationskoordinator 63 aufbaut. Über den Kommunikationskoordinator kann auf Adapter 64 zugegriffen werden, über die auf den Diagnosestecker 60 oder andere Transportprotokolle 67, die beispielsweise das TCP/IP-Protokoll umfassen, zugegriffen werden.

[0018] Anhand von Fig. 4 soll erläutert werden, wie das CAN-Snap-Diagnosemodul 53 nach Fig. 3 Daten eines CAN-Datenbusses protokolliert. Untereinander sind dann die binären Signale "Klemme 15", "Klemme 50" und "KD-Bit-Bremse" jeweils gegen die Zeit aufgetragen. Darunter sind die Batteriespannung und die Geschwindigkeit jeweils als Graphen gegen die Zeit dargestellt. Das CAN-Snap-Modul ist in diesem Ausführungsbeispiel so konfiguriert, dass es Informationen, die diese aufgeführten Signale betreffen, aus den Datenpaketen extrahiert, die über den CAN-Datenbus übertragen werden. Beim Protokollieren wird den einzelnen Signalwerten, die ermittelt sind, jeweils ein Zeitstempel zugeordnet. Diese Daten werden in einem Speicher abgelegt. Dieses kann ein flüchtiger Speicher für eine zeitnahe Auswertung oder ein anderes Speichermedium sein, in dem die Daten für eine zeitversetzte Diagnose gespeichert werden. Anhand der so protokollierten Daten lassen sich die dargestellten Graphen aus den Daten produzieren. Dargestellt sind die Signalverläufe für ein Anrollen eines Fahrzeugs vor einer geschlossenen Schranke. Zu einem Zeitpunkt A wird der Motor ausgeschaltet, was durch ein Abfallen des Klemme-15-Signals angedeutet ist. Zu einem Zeitpunkt B wird die Klemme 15 erneut geschlossen und anschließend die Klemme 50 geschlossen (Zeitpunkt C), was ein Starten des Motors bewirkt. Wie sich aus dem Batteriespannungssignal 70 ergibt, sinkt die Batteriespannung zum Zeitpunkt B mit dem Einschalten der Klemme 15 (Einschalten der Zündung) ab. Ein noch stärkerer Spannungsabfall tritt mit dem Schließen der Klemme 50 (Motorstart) ein. Anhand des Batteriespannungssignals 70 lässt sich ermitteln, dass die Batteriespannung für 250 ms unterhalb eines Batteriespannungsschwellenwertes 74 von 8 V liegt. Für diesen Zeitraum ist für einige Steuergeräte keine zuverlässige Funktion garantiert, da deren Spannungsversorgung nicht ausreichend ist. Das Erfassen der Signaldaten mit Hilfe des CAN-Snap-Verfahrens schafft die Möglichkeit, komplexe Abläufe zeitlich zu analysieren und Korrelationen zwischen Daten herzustellen und auszuwerten, um die Diagnose des Fahrzeugs und der Fahrzeugsysteme zu verbessern.

[0019] Bezugszeichenliste

1 Fahrzeug

2 als Motorsteuergerät ausgestaltetes Fahrzeugsystem

3 als Bremsensteuergerät ausgestaltetes Fahrzeugsystem

4 als Getriebesteuergerät ausgestaltetes Fahrzeugsystem

5 als Komfortsteuergerät ausgestaltetes Fahrzeugsystem

6 als Bremsensteuergerät ausgestaltetes Fahrzeugsystem

7 als Türsteuergerät ausgestaltetes Fahrzeugsystem

8 Radio

9 als Navigationssteuergerät ausgestaltetes Fahrzeugsystem

10 als Telematiksteuergerät ausgestaltetes Fahrzeugsystem

11 Schalttafel

12, 13 als weitere Steuergeräte ausgestaltete Fahrzeugsysteme

14 als Gateway ausgestaltetes Fahrzeugsystem

15 CAN-Antriebs-Datenbus

16 CAN-Komfort-Datenbus

17 CAN-Infotainment-Datenbus

18 CAN-Kombi-Datenbus

19 CAN-Diagnose-Datenbus

20 fahrzeuginternes Testgerät

21 Diagnoseframework

22 Zentraldiagnosemodul

23 Systemdiagnosemodul

24 CAN-Snap-Diagnosemodul

25 Telemetriedatenkoordinierungsdiagnosemodul

26 Prüfmodul

27 Linie, die Zugriffe des Diagnoseframeworks auf Fahrzeugsysteme andeutet

28 Linie, die Zugriffe des externen Testgeräts auf die fahrzeuginterne Diagnose andeutet

29 Linie, die Diagnosezugriffe nach dem Stand der Technik andeutet

30 Fahrzeug

31 fahrzeugexternes Testgerät

32 Diagnoseeinheit

33 Diagnoseframework

34 Diagnosemodule

35 Fahrzeug-Datenbus

36 Fahrzeugsysteme

37 weiterer Fahrzeug-Datenbus

38 externe Diagnosemodule

39 Diagnoseapplikation

40 Diagnoseeinheit

41 Speicher

42 Betriebssystemsoftwarekern

43 Betriebssystem-Anwendungsprogramm-Schnittstelle (BS-API)

44 Diagnoseframework

45 Schnittstelle

46 CAN-Anwendungsprogramm-Schnittstelle (CAN-API)

47 CAN-Softwarekern

48 physikalische CAN-Schnittstellen

49 Bandwidth-Allocation-Protocol

50 ISO-Transportprotokoll

51 KWP2000-Protokoll

52 Diagnosemodul

53 CAN-Snap-Diagnosemodul

54 Prüfdiagnosemodul

55 Systemdiagnosemodul

56 Telemetriedatenkoordinierungsdiagnosemodul

57 funktionsorientiertes Diagnosemodul

58 weitere Diagnosemodule

59 CAN-Datenbusvernetzung im Fahrzeug

60 Diagnosestecker

61 fahrzeugexternes Testgerät

62 Systemkonfigurationskoordinator (SKK)

63 Kommunikationskoordinator

64 Adapter

65 Kommunikationsprotokolle

72 Betriebsspannung

74 Batteriespannungsschwellenwert

A-C Zeitpunkte

Ansprüche

1. Vorrichtung in einem Fahrzeug (1) für eine Diagnose durch einen Fahrzeug-Datenbus (15-18; 35) vernetzter Fahrzeugsysteme (2-14; 36), umfassend eine Diagnoseeinheit (32; 40), die eine Schnittstelle (45) für ein Austauschen von Informationen über den Fahrzeug-Datenbus (15-18; 35) umfasst,
dadurch gekennzeichnet, dass
auf die Schnittstelle (45) ein Diagnoseframework (21; 33; 44) aufsetzt, das eine Anwendungsprogramm-Schnittstelle (API) für Diagnosemodule (22-26; 34; 52-58) bereitstellt, die zum Ausführen der fahrzeuginternen Diagnose der einzelnen Fahrzeugsysteme (2-14; 36) ausgestaltet sind, wobei mehrere Diagnosemodule (22-26; 34; 52-58) zeitgleich parallel auf dem Diagnoseframework (21; 33; 44) ausgeführt werden und das Diagnoseframework (21; 33; 44) einen Zugriff der Diagnosemodule (22-26; 34; 52-58) auf die Fahrzeugsysteme (2-14; 36) koordiniert.

2. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass mindestens eines der Diagnosemodule (22-26; 34; 52-58) ausgestaltet ist, die Fahrzeugsysteme (2-14; 36) orientiert an Fahrzeugfunktionen zu analysieren.

3. Vorrichtung nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Diagnoseframework (21; 33; 44) einen Teil der von den Fahrzeugsystemen (2-14; 36) übermittelten Daten in einem Speicherbereich vorhält, um die Anzahl der Zugriffe der Diagnosemodule (22-26; 34; 52-58) auf die Fahrzeugsysteme (2-14; 36) zu verringern.

4. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Diagnoseframework (21; 33; 44) einen zentralen Fehlerereignisspeicher umfasst, in dem Fehlerereignisse der vernetzten Fahrzeugsysteme (2-14; 36) gemeinsam abgelegt sind.

5. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Diagnoseeinheit (32; 40) über den Fahrzeug-Datenbus oder über eine weitere Schnittstelle (19) mit einem fahrzeugexternen Testgerät (20; 3; 61) verknüpfbar ist, wobei ein Datenaustausch zwischen dem fahrzeugexternen Testgerät (20; 3; 61) und den Diagnosemodulen (22-26; 34; 52-58) oder den Fahrzeugsystemen (2-14; 36) über das Diagnoseframework (21; 33; 44) erfolgt.

6. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Diagnoseframework (21; 33; 44) den Diagnosemodulen (22-26; 34; 52-58) Diagnosefunktionen und oder Diagnoseroutinen und/oder Speicher (41) und/oder Rechenkapazität zentral bereitstellt.

7. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass von mindestens zwei der Diagnosemodule (22-26; 34; 52-58) dieselbe Funktion, Ressource und/oder Diagnoseroutine verwendbar ist.

8. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Diagnosemodule (22-26; 34; 52-58) miteinander Daten und/oder Informationen über das Diagnoseframework (21; 33; 44) austauschen.

9. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Fahrzeugsysteme (2-14; 36) Steuergeräte umfassen.

10. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Diagnoseframework (21; 33; 44) in ein Steuergerät eines der Fahrzeugsysteme integriert ist, welches vorteilhafterweise eine Multifunktionsanzeigebedienvorrichtung ist.

11. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass der Fahrzeug-Datenbus (15-18; 35) ein CAN-Bus ist und mindestens eines der Diagnosemodule (22-26; 34; 52-58) als CAN-Snap=Modul (24; 53) ausgestaltet ist, um vorwählbare CAN-Businformationen zu protokollieren.

12. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass ein Speicher in dem Diagnoseframework (21; 33; 44) vorgesehen ist, um darin die protokollierten CAN-Businformationen abzulegen.

13. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das mindestens eine als CAN-Snap-Modul (24; 53) ausgestaltete Diagnosemodul und/oder mindestens ein weiters der Diagnosemodule (22-26; 34; 52-58) ausgestaltet sind, die protokollierten CAN-Businformationen in Echtzeit, insbesondere hinsichtlich eines Schlechtverhaltens und/oder einer Abweichung von einem Gutverhalten, zu analysieren.

14. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass mindestens eines der Diagnosemodule (22-26; 34; 52-58) ausgestaltet ist, bei einem Feststellen eines Fehlerereignisses das CAN-Snap-Modul (24; 53) entsprechend des Fehlerereignisses zu konfigurieren, um die zu protokollierenden Daten und/oder Signale festzulegen.

Zeichnung