DE102005044236A1

DE102005044236A1 - Diagnosegerät

Info

Publication number: DE102005044236A1
Application number: DE200510044236
Authority: DE
Inventors: Volker Lantzsch; Ulrich Herrmann; Bodo Howell Seiferth; Jason Canton Stombaugh
Original assignee: Volkswagen AG
Current assignee: Volkswagen AG
Priority date: 2005-09-16
Filing date: 2005-09-16
Publication date: 2007-03-29
Anticipated expiration: 2025-09-17
Also published as: DE102005044236B4

Abstract

Es wird ein Diagnosegerät (1) eingerichtet für eine Kommunikation mit einem Fahrzeug (7), wobei das Fahrzeug (7) ein Kommunikations-System (5) aufweist, wobei der Kommunikation ein Protokoll zu Grund liegt, vorgeschlagen. Dieses zeichnet sich dadurch aus, dass das Diagnosegerät (1) für eine automatische Simulation verschiener zeitkritischer Parameter und/oder Protokoll-Parameter des Kommunikations-Systems (5) des Fahrzeugs (7) eingerichtet ist.

Description

Die Erfindung betrifft ein Diagnosegerät gemäß dem Oberbegriff des Anspruchs 1 sowie ein Verfahren zum Durchführen eines On-Board-Diagnose-Kommunikations-Tests für ein Fahrzeug.

Diagnosegeräte der gattungsgemäßen Art sind bekannt. Moderne Kraftfahrzeuge verfügen über eine Vielzahl von Steuergeräten, die miteinander kommunizieren. Hierzu wird vorzugsweise ein fahrzeugeigenes Kommunikationssystem, beispielsweise ein sogenanntes Controller-Area-Network (CAN) – auch unter der Bezeichnung CAN-BUS bekannt – verwendet. Zunehmend weisen Kraftfahrzeuge auch umfangreiche Überwachungssysteme – bekannt auch als On-Board-Diagnose (OBD) – auf. OBD wird hauptsächlich dazu verwendet, um die vom Gesetzgeber geforderten Emissionsgrenzwerte auch im Alltag einzuhalten. Hierzu müssen das Motorsystem und die Komponenten, also die entsprechenden Steuergeräte, ständig überwacht werden. Hierzu ist es bekannt, fahrzeugeigen, sogenannte Scan-Tools über den CAN-BUS mit den zu überwachenden Steuergeräten zu verbinden. Die entsprechenden Tests für eine OBD können dann vor, während oder nach dem Fahrbetrieb durchgeführt werden. Um eine fehlerfreie OBD sicherzustellen, ist es bekannt, die OBD mit einem nicht zum Fahrzeug gehörenden Diagnosegerät zu testen, wie beispielsweise in der DE 102 49 659 A1 offenbart. Dabei werden insbesondere speziell angepasste Tests mit dem OBD-System durchgeführt, um in der Vergangenheit aufgetretene Probleme zu beseitigen.

Aufgabe der Erfindung ist es, die Testmöglichkeiten für OBD-Systeme in Kraftfahrzeugen weiter zu verbessern.

Diese Aufgabe wird mit einem Diagnosegerät mit den Merkmalen des Anspruchs 1 gelöst. Das Diagnosegerät ist eingerichtet für eine Kommunikation mit einem Fahrzeug, das ein Kommunikationssystem aufweist. Dem Kommunikationssystem des Fahrzeugs liegt ein entsprechendes Protokoll zugrunde. Bei dem Protokoll kann es sich beispielsweise um ein normiertes Protokoll oder um ein normiertes Protokoll mit einem herstellerspezifischen Protokolldialekt handeln. Erfindungsgemäß ist das Diagnosegerät für eine automatische Prüfung und/oder Simulation zeitkritischer Parameter und/oder Protokollparameter des Kommunikationssystems des Fahrzeugs eingerichtet. Das Diagnosegerät kann also einen automatisierten Test für das Kommunikationssystem durchführen. Vorzugsweise weist das Diagnosegerät eine Zeit-Kontroll-Einheit für die Prüfung der zeitkritischen Parameter und eine Protokoll-Kontroll-Einheit für die Prüfung der Protokoll-Parameter auf. Es ist denkbar, anstatt der zwei einzelnen Kontrolleinheiten eine gemeinsame Kontrolleinheit für die Prüfungen vorzusehen.

Bei einem bevorzugten Ausführungsbeispiel handelt es sich bei dem Kommunikationssystem des Fahrzeugs um ein On-Board-Diagnose-System (OBD). Mit Hilfe des Diagnosegeräts kann also ein fahrzeugeigenes OBD-System automatisiert getestet werden.

Ein überdies bevorzugtes Ausführungsbeispiel sieht vor, dass das Diagnosegerät für eine Simulation wahlweise entweder eines OBD-relevanten Steuergeräts oder als Scan-Tool für eine Überprüfung der Kommunikation eines oder mehrerer OBD-relevanter Steuergeräte des OBD-Systems des Fahrzeugs eingerichtet ist. Das Diagnosegerät kann also innerhalb des fahrzeugeigenen OBD-Systems entweder in Funktion eines Steuergeräts oder als Scan-Tool in Erscheinung treten. Dabei kann das Diagnosegerät entsprechende Reize zum Testen der OBD des Fahrzeugs aussenden. Für den Fall, dass das Diagnosegerät ein OBD-relevantes Steuergerät simuliert, tritt das Diagnosegerät für das OBD-System als Slave in Erscheinung. Dies kann zum Testen und/oder Reizen eines fahrzeugeigenen Scan-Tools für das fahrzeugeigene OBD-System ausgenutzt werden. Für den Fall, dass das Diagnosegerät ein Scan-Tool simuliert, tritt dieses als Master in Erscheinung und kann eines oder mehrere OBD-relevante Steuergeräte des Fahrzeugs entsprechend reizen und testen.

Ein weiteres bevorzugtes Ausführungsbeispiel sieht vor, dass das Diagnosegerät dazu eingerichtet ist, wahlweise das Verhalten eines fahrzeugeigenen OBD-Scan-Tools oder des Steuergeräts/der Steuergeräte zu protokollieren. Mithin können die aufgrund der Reize des Diagnosegerätes erfolgten Reaktionen des OBD-Systems des Fahrzeugs zur Auswertung des jeweils durchgeführten Tests mitprotokolliert, also dokumentiert werden. Über die Dokumentation kann eine bei dem durchgeführten Test auffällige OBD-Komponente des Fahrzeugs leicht lokalisiert werden.

Ein überdies bevorzugtes Ausführungsbeispiel sieht vor, dass die Kommunikation über eine Diagnoseschnittstelle erfolgt. Die Kommunikation über die Diagnoseschnittstelle erfolgt über ein entsprechendes Kommunikationsprotokoll, beispielsweise nach dem ISO 9141-2, SAE J1850, ISO 14230-4 (KWP2000) oder dem SAE J1708 Standard oder einem beliebigen anderen Standard. Über die Diagnoseschnittstelle kann das Diagnosegerät mit dem zu überprüfenden Kommunikationssystem des Fahrzeugs verbunden werden.

Ein überdies bevorzugtes Ausführungsbeispiel sieht vor, dass die Kommunikation über einen BUS des Kommunikationssystems des Fahrzeugs erfolgt. Die Kommunikation kann beispielsweise direkt über einen CAN-BUS des Fahrzeugs erfolgen. Vorzugsweise erfolgt die Kommunikation des Diagnosegerätes und der entsprechenden OBD-Steuergeräte gemäß dem Standard ISO 15765-4. Vorzugsweise weist das Diagnosegerät eine Datenschnittstelle zur direkten Ankopplung an den CAN-BUS des Fahrzeugs auf. Die Datenschnittstelle kann als CAN zu RS232 oder als CAN zu USB-Wandler ausgebildet sein. Je nach verwendetem CAN-Standard kann es sich beispielsweise um einen ISO 9141 zu RS232 oder einen ISO 9141 zu USB-Wandler handeln.

Ein überdies bevorzugtes Ausführungsbeispiel sieht vor, dass das Diagnosegerät vorprogrammierte Antworten auf Anfragen, vorzugsweise auf alle möglichen Anfragen, des Scan-Tools enthält. Es ist also möglich, im Slave-Betrieb entsprechende Antworten eines Steuergeräts auf Anfragen eines Scan-Tools in das Kommunikationssystem des Fahrzeugs einzuspielen. Die hierdurch entsprechend hervorgerufenen Reaktionen der/des angeschlossenen fahrzeugeigenen Scan-Tools erlauben Rückschlüsse auf dessen korrekte Funktion. Mithin kann die Kommunikation der verschiedenen Scann-Tools des Fahrzeugs überprüft werden.

Ein weiteres bevorzugtes Ausführungsbeispiel sieht vor, dass das Diagnosegerät verschiedene Anfragen eines beliebigen Scan-Tools für ein fahrzeugeigenes OBD-System enthält. Es ist also möglich, im Master-Betrieb entsprechende Anfragen eines Scan-Tools in das Kommunikationssystem des Fahrzeugs einzuspielen. Die hierdurch entsprechend hervorgerufenen Reaktionen der angeschlossenen Steuergeräte erlauben Rückschlüsse auf dessen korrekte Funktion. Folglich lässt sich so die Kommunikation der verschiedenen OBD-relevanten Steuergeräte des Fahrzeugs überprüfen.

Ein weiteres bevorzugtes Ausführungsbeispiel sieht vor, dass das Diagnosegerät für die Simulation eines oder mehrerer OBD-relevanter Steuergeräte dazu eingerichtet ist, eine oder mehrere Fehlersimulation(en) in das Kommunikationssystem des Fahrzeugs einzuspielen. Dabei kann es sich beispielsweise um innerhalb der Grenzwerte verschobene Timings, um veränderte Check-Summen, um unvollständig gesendete Botschaften, um eine mit einem falschen Header aufgebaute Botschaft, um eine falsche Antwortbotschaft und/oder um Antworten mehrerer Steuergeräte handeln. Mithin können die fahrzeugeigenen Scan-Tools gezielt gereizt und getestet werden.

Ein überdies bevorzugtes Ausführungsbeispiel sieht vor, dass das Diagnosegerät für die Simulation des Scan-Tools dazu eingerichtet ist, eine oder mehrere Fehlersimulation(en) in das Kommunikationssystem des Fahrzeugs einzuspielen. Hierzu ist es ebenfalls denkbar, Timings innerhalb der Grenzwerte zu verschieben, Check-Summen zu verändern, Botschaften unvollständig zu senden, Botschaften mit einem falschen Header aufzubauen und/oder Anfragen nach nicht unterstützten Services in die Kommunikation des fahrzeugeigenen Kommunikationssystems einzuspielen. In diesem Modus des Diagnosegeräts, also im Master-Betrieb, ist es mithin möglich, die verschiedenen OBD-relevanten Steuergeräte des Fahrzeugs zu reizen und entsprechend zu testen.

Ein überdies bevorzugtes Ausführungsbeispiel sieht vor, dass das Diagnosegerät ein entsprechend programmtechnisch eingerichteter PC ist. Vorteilhafterweise sind PC's günstig herstellbar und vielerorts verfügbar. Die für die programmtechnische Einrichtung des PC's notwendigen Daten können auf einem beliebigen Datenträger gespeichert zur Verfügung gestellt werden und/oder über ein Netzwerk bereitgestellt beziehungsweise zu dem PC übertragen werden.

Die der Erfindung zugrunde liegende Aufgabe wird außerdem durch ein Verfahren mit den Merkmalen des Anspruchs 12 gelöst. Vorzugsweise wird das Verfahren mit einem zuvor beschriebenen Diagnosegerät durchgeführt. Erfindungsgemäß wird die OBD-Kommunikation des Fahrzeugs automatisch und bidirektional getestet. Mithin ist es möglich, mit geringem Aufwand alle OBD-relevanten Funktionen des Fahrzeugs zu testen. Vorzugsweise kann dazu bei der Durchführung des Verfahrens das Diagnosegerät in einem Master-Modus ein fahrzeugeigenes Scan-Tool simulieren und/oder in einem Slave-Modus wahlweise eines oder mehrere OBD-relevante Steuergeräte simulieren.

Bei einer bevorzugten Ausführungsform des Verfahrens werden eine oder mehrere Fehlersimulationen eines oder mehrerer onboard-relevanter Steuergeräts/Steuergeräte und oder eines Scan-Tools des Kommunikations-System des Fahrzeugs eingespielt. Vorzugsweise wird zusätzlich das Verhalten des/der OBD-relevanten Steuergeräts/Steuergeräte und/oder des Scan-Tools mitprotokolliert. Es ist also denkbar, über die Fehlersimulationen und den entsprechenden Master- und Slave-Betrieb des Diagnosegeräts bei der Durchführung des Verfahrens alle OBD-relevanten Funktionen eines Fahrzeugs automatisiert zu testen. Hierzu können alle denkbaren Anfragen und zugehhörige Antworten, wie oben beschrieben, automatisiert in das OBD-System des Fahrzeugs eingespielt, mitprotokolliert und mithin getestet werden.

Weitere Vorteile ergeben sich aus den übrigen Unteransprüchen, der Zeichnung sowie der dazugehörigen Beschreibung. Im Folgenden wird ein Ausführungsbeispiel der Erfindung anhand der Zeichnung näher erläutert:
1 zeigt ein schematisiert dargestelltes Kommunikationssystem eines Fahrzeugs mit einem daran angeschlossenen Diagnosegerät und
2 zeigt ein Datenlaufschema anhand eines schematisiert dargestellten Diagnosegeräts mit einzelnen Funktionselementen.
In den Figuren sind gleiche oder in ihrer Funktion ähnliche Teile mit gleichen Bezugszeichen versehen.
1 zeigt ein Diagnosegerät 1, das über eine Datenschnittstelle 3 an ein Kommunikationssystem 5 eines Fahrzeugs 7, das lediglich durch ein gestricheltes Rechteck 9 angedeutet ist, angeschlossen ist. Die Datenschnittstelle 3 ist dazu ausgelegt einzelne Dateneinheiten des zu Grunde liegenden Protokolls bidirektional zu übertragen. Bei dem Kommunikationssystem 5 des Fahrzeugs 7 handelt es sich bevorzugt um ein On-Board-Diagnose-System 11 mit einer Vielzahl von Steuergeräten 13 und zumindest einem Scan-Tool 15. Das Scan-Tool 15 und die Steuergeräte 13 kommunizieren über einen CAN-BUS 17 miteinander. Hierzu verfügen die Steuergeräte 13, das Scan-Tool 15 sowie die Datenschnittstelle 3 über ein entsprechendes Protokoll, beispielsweise nach einem der Standards ISO 11898, ISO 1159, ISO 9141, ISO 15765-4 oder Key-Word-Protokoll (KWP) 2000 etc. Es ist jedoch auch denkbar, das Diagnosegerät 1 über eine Diagnoseschnittstelle direkt mit einem oder mehreren der Steuergeräte 13 oder mit dem Scan-Tool 15 zu verbinden.
Die Datenschnittstelle 3 verfügt über einen Wandler, der das CAN-Protokoll in ein für das Diagnosegerät 1 zugängliches Datenformat übersetzt. Dabei kann es sich beispielsweise um einen CAN zu RS232 oder CAN zu USB-Wandler handeln.
Vorzugsweise handelt es sich bei dem Diagnosegerät um einen handelsüblichen PC, der mit einer entsprechenden Schnittstelle zur Kommunikation mit der Datenschnittstelle 3 ausgerüstet ist. Die Datenschnittstelle 3 kann vorzugsweise auch in dem Diagnosegerät integriert sein. Ebenso gut ist es möglich, die Datenschnittstelle 3 im Fahrzeug 7 vorzusehen.
Das Diagnosegerät ist dazu eingerichtet, zumindest ein Protokoll, beispielsweise das Key-Word-Protokoll (KWP) 2000 oder einen der genannten CAN-Standards zu beherrschen und/oder zu testen. Vorzugsweise kann das Diagnosegerät 1 auch zum Testen unterschiedlicher, beispielsweise herstellerspezifischer Protokolle oder Protokoll-Dialekte ausgerüstet sein.
Im vorliegenden Ausführungsbeispiel gemäß 1 ist das Diagnosegerät 1 dazu eingerichtet, in einem Master-Modus und in einem Slave-Modus betrieben zu werden. In dem Master-Modus simuliert das Diagnosegerät 1 ein an den Datenverkehr des CAN-BUSses 17 direkt teilnehmenden Scan-Tools. Dabei kann die Funktion eines beliebigen Scan-Tools oder die Funktion des Scan-Tools 15 direkt von dem Diagnosegerät 1 simuliert werden. In dem Slave-Modus simuliert das Diagnosegerät 1 die Funktion zumindest eines an dem Datenverkehr des CAN-BUSses 17 teilnehmenden Steuergeräts 13 oder ein beliebiges anderes OBD-relevantes Steuergerät. Bei den Steuergeräten 13 handelt es sich um OBD-relevante Steuergeräte, beispielsweise um ein Motorsteuergerät, um ein Steuergerät zur Erkennung abgasrelevanter Größen oder Ähnlichem.
Vorteilhafterweise durchläuft das Diagnosegerät 1 automatisch den Slave-Modus und den Master-Modus, um dabei automatisch zeitkritische Parameter sowie Protokoll-Parameter des entsprechenden Kommunikations-Systems 5 des Fahrzeugs 7 mit dem entsprechenden Protokoll zu simulieren und dabei das OBD-System 11 des Fahrzeugs 7 zu testen. Bei der automatisch ablaufenden Simulation können nicht protokoll-konforme Reaktionen des zu testenden OBD-Systems 11 gegebenenfalls provoziert und detektiert werden. Vorteilhafterweise werden alle durch das Diagnosegerät 1 hervorgerufenen Reaktionen des Kommunikationssystems 5 bzw. des OBD-Systems 11 des Fahrzeugs 7 mit protokolliert und auf ihre Korrektheit hin überprüft. Für den Fall, dass alle Reaktionen bzw. Antworten mit den entsprechenden im Diagnosegerät 1 vorgespeicherten Soll-Antworten übereinstimmen, wird der Test als bestanden deklariert. Zum Testen aller Funktionalitäten des OBD-Systems 11 des Fahrzeugs 7 werden von dem Diagnosegerät 1 sowohl im Master-Modus sowie im Slave-Modus alle denkbaren Fehlersituationen in die Kommunikation des CAN-BUSses 17 des Fahrzeugs 7 eingespielt. Dabei kann es sich beispielsweise um eine Verschiebung des Timings innerhalb der Grenzwerte, um veränderte Check-Summen, um unvollständige Botschaften, um Botschaften mit falschem Header, um falsche Antwortbotschaften, um eine Überlagerung mehrerer Antworten von mehreren Steuergeräten und/oder um Anfragen nach nicht unterstützten Services handeln. Die gezielte Einspielung von Fehlern in das Kommunikationssystem 5 des Fahrzeugs 7 ermöglicht es, denkbare Probleme bereits im Vorfeld zu simulieren. Mithin ist das Diagnosegerät in der Lage, auch solche Tests durchzuführen bei denen automatisch Probleme erkannt werden können, die bisher erst im Praxisbetrieb entdeckt und daraufhin spezifisch simuliert oder getestet werden mussten.
2 zeigt schematisiert das Diagnosegerät 1 in Kommunikation über die Daten-Schnittstelle 3 mit dem OBD-System 11. Schematisiert sind in das Diagnosegerät 1 Funktionselemente des Diagnosegeräts 1 eingezeichnet, aus denen das Datenlaufschema für eine Protokoll-Simulation bzw. Diagnose ersichtlich ist. Pfeile symbolisieren Datenflüsse und/oder Verbindungen.
Das Diagnosegerät 1 verfügt über eine Kommunikations-Einheit 19, die den seriellen Datenaustausch mit der Datenschnittstelle 3 kontrolliert (beispielsweise nach KWP 2000 oder ISO 15765-4).
Durch Pfeile 21 und 23 ist eine Eingabe-Ausgabe-Schnittstelle des Diagnosegeräts 1 angedeutet. Dabei bedeutet der Pfeil 21, dass das Diagnosegerät 1 entsprechend durch einen Benutzer konfigurierbar ist. Der Pfeil 23 deutet an, dass entsprechende Diagnose bzw. Test-Ergebnisse ausgegeben werden können. Dabei handelt es sich insbesondere für jede analysierte und getestete Funktion um die Information, ob der Test bestanden oder nicht bestanden wurde. Durch die Konfiguration des Benutzers, wie durch den Pfeil 21 angedeutet, kann das Diagnosegerät beispielsweise auf ein zu analysierendes Protokoll, beispielsweise für KWP 2000 in Verbindung mit ISO 9141 oder um ein CAN-Protokoll handeln.
Nach erfolgter Konfiguration des Diagnosegeräts 1 durch den Benutzer generiert das Diagnosegerät ein zu sendendes Protokoll-Telegramm. Dafür ist eine Protokol-Einheit 25 vorgesehen. Vorzugsweise handelt es sich bei dem erzeugten Protokoll-Telegramm um eine Vielzahl einzelner Protokoll-Nachrichten, beispielsweise um die Gesamtheit aller implementierten Nachrichtentypen. Darüber hinaus sollte das Protokoll-Telegramm aber auch Ausnahmesituationen des Protokolls enthalten, wie beispielsweise fehlerhafte oder in dem falschen Zeitrahmen verschickte Bytes. Das Protokoll-Telegramm wird in einzelnen Nachrichten an eine Assembler-Einheit 27 des Diagnosegeräts 1 weitergeleitet. Die Assembler-Einheit 27 versendet über die Kommunikations-Einheit 19 und die Datenschnittstelle 3 einzelne Dateneinheiten, beispielsweise einzelne Bytes oder einen einzelnen CAN-Rahmen an das OBD-System 11. Die entsprechenden Reaktionen des OBD-Systems 11 werden in entgegengesetzter Richtung über die Datenschnittstelle 3 sowie über die Kommunikations-Einheit 19 des Diagnosegeräts 1 an einen Assembler-Empfänger 29 des Diagnosegeräts 1 zurückgesendet. Die von dem Assembler-Empfänger 29 empfangenen Dateneinheiten werden an eine Aufzeichnungseinheit 31 des Diagnosegeräts 1 weitergeleitet.
Vorteilhafterweise verfügt das Diagnosegerät 1 über eine Zeitkontrolleinheit 33. Die Zeitkontrolleinheit 33 ermöglicht es, auch zeitkritische Funktionen des OBD-Systems 11 zu analysieren. Hierzu stellt die Zeitkontrolleinheit 33 des Diagnosegeräts 1 sicher, dass jede durch den Assembler-Empfänger 29 des Diagnosegeräts 1 empfangene Dateneinheit mit einem Zeitstempel versehen wird. Bevorzugt gibt der Zeitstempel nicht nur darüber Auskunft, wann die entsprechende Dateneinheit empfangen wurde, sondern auch darüber, wann die diese Reaktion hervorrufende Dateneinheit über die Assembler-Einheit 27 an das OBD-System 11 gesendet wurde. Mithin ist dazu durch die Zeitstempelung mittels der Zeitkontrolleinheit 33 eine Laufzeitkontrolle der einzelnen abgesandten Protokoll-Nachrichten möglich. Die Zeitkontrolleinheit 33 kommuniziert also sowohl mit der Assembler-Einheit 27 wie auch mit dem Assembler-Empfänger 29, was durch 2 Pfeile 35 angedeutet ist.
Außerdem verfügt das Diagnosegerät 1 über eine Protokoll-Kontroll-Einheit 37. Die Protokoll-Kontroll-Einheit 37 kommuniziert mit der Protokoll-Einheit 25 und der Aufzeichnungseinheit 31, was durch zwei Pfeile 39 angedeutet ist. Die Protokoll-Kontroll-Einheit 37 vergleicht dabei die jeweils erwartete Reaktion, die durch die jeweils gesendete Protokoll-Einheit des Protokoll-Telegramms hervorgerufen wurde mit einer vorgespeicherten Soll-Reaktion des OBD-Systems 11. Außerdem wertet die Protokoll-Kontroll-Einheit 37 die von der Zeit-Kontroll-Einheit 33 zugefügten Zeitstempel aus. Mit Hilfe dieser Auswertungen trifft die Protokoll-Kontroll-Einheit 37 für jede entsprechende Testfunktion des Diagnosegeräts 1 die Entscheidung, inwieweit der jeweilige Teil-Test bestanden bzw. nicht bestanden wurde. Diese Information kann dann entsprechend über die Eingabe-Ausgabe-Schnittstelle, wie durch den Pfeil 23 angedeutet, ausgegeben werden.
Im Folgenden wird unter Bezug auf die 1 und 2 ein Verfahren zum Durchführen eines OBD-Kommunikations-Tests für das Fahrzeug 7 näher erläutert.
Durch eine entsprechende Abarbeitung eines Protokoll-Telegramms in der Protokoll-Einheit 25 des Diagnosegeräts 1 wird das OBD-System 11 des Fahrzeugs 7 automatisch bidirektional getestet. Vorzugsweise ist das Protokoll-Telegramm der Protokoll-Einheit 25 so gestaltet, dass das Diagnosegerät 1 dabei in einem Master-Modus und in einem Slave-Modus betrieben wird, wobei das Diagnosegerät 1 über die Datenschnittstelle 3 so betrieben wird, dass das Diagnosegerät 1 dabei zumindest ein OBD-relevantes Steuergerät 13 und anschließend ein Scan-Tool, beispielsweise analog dem Scan-Tool 15 des Fahrzeugs 7, simuliert.
Vorzugsweise wird über das Diagnosegerät 1 eine oder mehrere Fehlersimulationen eines OBD-relevanten Steuergeräts und/oder eines Scan-Tools in das Kommunikations-System 5 des Fahrzeugs 7 eingespielt. Die entsprechenden Reaktionen des OBD-Systems 11 des Fahrzeugs 7 können vorteilhafter Weise in der Aufzeichnungseinheit 31 des Diagnosegeräts 1 mitprotokolliert werden. Dies ermöglicht es, sowohl die Funktion der Steuergeräte 13 des OBD-Systems 11 sowie die Funktion des Scan-Tools 15 des OBD-Systems 11 entsprechend zu testen. Vorteilhafterweise kann insbesondere mit Hilfe der Zeitstempelung durch die Zeit-Kontroll-Einheit 33 auch das Zeitverhalten des OBD-Systems ermittelt, protokolliert und getestet werden.

1: Diagnosegerät
3: Daten-Schnittstelle
5: Kommunikations-System
7: Fahrzeug
9: Rechteck
11: OBD-System
13: Steuergerät
15: Scan-Tool
17: CAN-BUS
19: Kommunikations-Einheit
21: Pfeil
23: Pfeil
25: Protokoll-Einheit
27: Assembler-Einheit
29: Assembler-Empfänger
31: Aufzeichnungs-Einheit
33: Zeit-Kontroll-Einheit
35: Pfeil
37: Protokoll-Kontroll-Einheit
39: Pfeil

Claims

Diagnosegerät (1) eingerichtet für eine Kommunikation mit einem Fahrzeug (7), wobei das Fahrzeug (7) ein Kommunikations-System (5) aufweist, wobei der Kommunikation ein Protokoll zu Grunde liegt, dadurch gekennzeichnet, dass das Diagnosegerät (1) für eine automatische Prüfung verschiedener zeitkritischer Parameter und/oder Protokoll-Parameter des Kommunikations-Systems (5) des Fahrzeugs (7) eingerichtet ist.
Diagnosegerät nach Anspruch 1, gekennzeichnet durch eine Zeit-Kontroll-Einheit (33) für die Prüfung der zeitkritischen Parameter und eine Protokoll-Kontroll-Einheit (37) für die Prüfung der Protokoll-Parameter.
Diagnosegerät nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass das Kommunikations-System (5) des Fahrzeugs (7) ein On-Board-Diagnose (OBD)-System (11) aufweist, und dass das Diagnosegerät (1) für eine Simulation eines OBD-relevanten Steuergeräts und eines Scan-Tools eingerichtet ist, insbesondere für eine Überprüfung der Kommunikation eines oder mehrerer OBD-relevanter Steuergeräte (13) und/oder eines eines Scan-Tools (15) des OBD-Systems (11) des Kommunikations-Systems (5) des Fahrzeugs (7).
Diagnosegerät nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass das Diagnosegerät (1) dafür eingerichtet ist, wahlweise das Verhalten eines OBD-Scan-Tools (15) des Fahrzeugs (7) oder des Steuergeräts/der Steuergeräte (13) mit zu protokollieren, insbesondere dafür eine Aufzeichnungseinheit (31) und die damit in Verbindung stehende Protokoll-Kontroll-Einheit (37) aufweist.
Diagnosegerät nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Kommunikation über eine Diagnose-Schnittstelle, insbesondere über eine Kommunikationseinheit (19), eine Assemblereinheit (27) und eine Assemblerempfängereinheit (29), erfolgt.
Diagnosegerät nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Kommunikation über einen BUS des Kommunikations-Systems (5) des Fahrzeugs, vorzugsweise über die Kommunikationseinheit (19), die Assemblereinheit (27) und die Assemblerempfängereinheit (29), insbesondere über eine Daten-Schnittstelle (3) und einen CAN-BUS (17), erfolgt.
Diagnosegerät nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass die Daten-Schnittstelle (3) als CAN zu RS232 oder CAN zu USB (Universal Serial BUS) ausgelegt ist.
Diagnosegerät nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Diagnosegerät (1) vorprogrammierte Antworten auf Anfragen, vorzugsweise auf alle möglichen Anfragen, des Scan-Tools (15) enthält, vorzugsweise gespeichert in einer Protokolleinheit (25).
Diagnosegerät nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Diagnosegerät (1) verschiedene Anfragen des Scan-Tools (15) enthält, vorzugsweise gespeichert in der Protokolleinheit (25).
Diagnosegerät nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Diagnosegerät (1) für die Simulation des OBD-relevanten Steuergeräts (13) dazu eingerichtet ist, eine oder mehrere der folgenden Fehlersimulationen in das Kommunikations-System (5) des Fahrzeugs (7) einzuspielen: – Innerhalb der Grenzwerte verschobene Timings, – Veränderte Checksummen, – Unvollständig gesendete Botschaften, – Botschaften mit falsch aufgebautem Header, – Falsch gesendete Antwortbotschaften, – Simulierte Antworten mehrerer Steuergeräte.
Diagnosegerät nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Diagnosegerät (1) für die Simulation des Scan-Tools (15) dazu eingerichtet ist, eine oder mehrere der folgenden Fehlersimulationen in das Kommunikations-System (5) des Fahrzeugs (7) einzuspielen: – Innerhalb der Grenzwerte verschobene Timings, – Veränderte Checksummen, – Unvollständig gesendete Botschaften, – Botschaften mit falsch aufgebautem Header, – Anfragen nach nicht unterstützten Services.
Verfahren zum Durchführen eines OBD-Kommunikations-Tests für ein Fahrzeug (7), insbesondere mit Hilfe eines Diagnosegeräts (1) nach einem der Ansprüche 1 bis 11, gekennzeichnet durch folgenden Schritt: – Bidirektionales, automatisches Testen der OBD-Kommunikation des Fahrzeugs (7).
Verfahren nach Anspruch 12, gekennzeichnet durch folgende zusätzliche Schritte: – Simulieren eines OBD-relevanten Steuergeräts (13), – Simulieren eines Scan-Tools (15).
Verfahren nach einem der Ansprüche 12 oder 13, gekennzeichnet durch folgenden zusätzlichen Schritt: – Einspielen einer oder mehrerer Fehlersimulationen eines OBD-relevanten Steuergeräts (13) und/oder eines Scan-Tools (15).
Verfahren nach einem der Ansprüche 12 bis 14, gekennzeichnet durch folgenden zusätzlichen Schritt: – Ermitteln und protokollieren des Verhaltens, insbesondere des Zeitverhaltens, des/der OBD-relevanten Steuergeräts/Steuergeräte (13) und/oder des Scan-Tools (15).