EP1796051B1 - Diagnosevorrichtungen in einem Fahrzeug mit Diagnoseframework für Diagnosemodule - Google Patents

Diagnosevorrichtungen in einem Fahrzeug mit Diagnoseframework für Diagnosemodule Download PDF

Info

Publication number
EP1796051B1
EP1796051B1 EP06090235A EP06090235A EP1796051B1 EP 1796051 B1 EP1796051 B1 EP 1796051B1 EP 06090235 A EP06090235 A EP 06090235A EP 06090235 A EP06090235 A EP 06090235A EP 1796051 B1 EP1796051 B1 EP 1796051B1
Authority
EP
European Patent Office
Prior art keywords
diagnostic
vehicle
framework
modules
vehicle systems
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Not-in-force
Application number
EP06090235A
Other languages
English (en)
French (fr)
Other versions
EP1796051A1 (de
Inventor
Heino Brose
Peter Braitschink
Gernot Rüb
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Audi AG
Volkswagen AG
Original Assignee
Audi AG
Volkswagen AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Audi AG, Volkswagen AG filed Critical Audi AG
Publication of EP1796051A1 publication Critical patent/EP1796051A1/de
Application granted granted Critical
Publication of EP1796051B1 publication Critical patent/EP1796051B1/de
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station

Definitions

  • the invention relates to a device in a vehicle for diagnosis by a vehicle data bus of networked vehicle systems, comprising a diagnostic unit comprising an interface for exchanging information about the vehicle data bus with the networked vehicle systems.
  • individual vehicle systems which preferably include controllers, are networked together by a vehicle data bus.
  • the individual vehicle systems each include a diagnostic unit which is integrated into the respective control unit of the vehicle system.
  • the diagnosis of the individual vehicle systems is carried out by the individual diagnostic units in the vehicle systems. Errors determined are stored in a fault memory in the individual vehicle systems.
  • a vehicle-external diagnostic and test device which is linked to the vehicle data bus, the individual diagnostic units or fault memory can be queried. A comprehensive analysis of the vehicle as a whole is made difficult by this approach.
  • similar diagnostic capacities are often maintained in the individual diagnostic units of the vehicle systems.
  • Such a diagnostic device is for example in the DE 102 54 393 A1 described.
  • a diagnostic control unit is connected to data and signal lines of a wiring harness and carries out functional tests of the components already installed during the production process.
  • the diagnostic results obtained are transmitted wirelessly and used to locate the motor vehicle during production.
  • the diagnostic device used in this case can be integrated into a control unit, which later also performs checking functions during operation of the vehicle.
  • individual test sections are carried out successively in order to check individual components of the produced vehicle.
  • the test program which is designed as software, can be replaced, a simultaneous execution of several test procedures is not provided. Thus, a complex diagnosis is particularly difficult if several vehicle components are to be checked in parallel.
  • the DE 10 2004 008 816 A discloses a framework structure for diagnosing engine data of a vehicle according to the preamble of claim 1.
  • the invention has for its object to provide a device for diagnosis by a vehicle data bus networked vehicle systems in which a simultaneous accelerated diagnosis of multiple vehicle systems is possible and an expandability and adaptation of the diagnostic capabilities in a modification of the vehicle after the original production easy is possible.
  • diagnostic framework keeps part of the data transmitted by the vehicle systems in a memory area in order to reduce the number of accesses of the diagnostic modules to the vehicle systems.
  • the diagnostic framework comprises a central fault memory in which the fault events of the networked vehicle systems are stored together has proven to be particularly advantageous.
  • an overview of fault events that have occurred can thus be obtained in a simple manner.
  • the results obtained during in-vehicle diagnostics are also used for vehicle maintenance and repair. It is therefore customary to couple vehicle-external test devices with the vehicle in order to read out the internal diagnostic results or to have specific diagnostic steps carried out on the vehicle systems and / or executed.
  • a preferred embodiment therefore provides in that the diagnostic unit can be linked via the vehicle data bus or via a further interface with a vehicle-external test device, data being exchanged between the vehicle-external test device and the diagnostic modules or the vehicle systems via the diagnostic framework.
  • the diagnostic framework can provide a uniform interface for access by an external test device. Thus, different vehicles can interact with one and the same external test device. It is only necessary to adapt the individual diagnostic frameworks of the different vehicles to the vehicle systems installed therein.
  • the diagnostic modules which are fitted in the application program interface of the diagnostic framework, can also be used universally.
  • the proposed procedure ensures that the results already determined by the in-vehicle diagnosis can be detected particularly easily and quickly. If, for example, a memory area is provided for the common storage of the fault events of the vehicle systems, then these fault events can be transmitted quickly to the external test device via the diagnostic framework without the need for access to the individual vehicle systems via the vehicle data bus. This speeds up vehicle diagnostics with an external test device.
  • the diagnostic framework is advantageously designed such that diagnostic functions and / or diagnostic routines and / or memory and / or computing capacity are provided centrally to the diagnostic modules.
  • diagnostic routines or memory areas of several diagnostic modules can be shared. This reduces the required storage and computing capacity in the vehicle.
  • the individual vehicle systems no longer have to be designed to carry out diagnostic functions on their own. This makes the individual vehicle systems easier and cheaper.
  • the proposed procedure is further characterized in that after completion of the vehicle, the diagnostic functionality can be extended and / or changed. It is not necessary to modify the individual vehicle systems, which is very expensive. Rather, it is sufficient to modify or replace individual or all diagnostic modules, or to add a new or several new diagnostic modules to the diagnostic unit.
  • a function-oriented diagnosis is usually unsatisfactory or even impossible with diagnostic modules that are integrated in the individual vehicle systems. Especially with a function-oriented diagnosis, many data and information of the individual vehicle systems of several functional diagnoses needed. By embedding the diagnostic modules in the diagnostic framework, it is achieved that the diagnostic framework can maintain this data centrally, so that the number of accesses to the vehicle systems and a load on the vehicle data bus is significantly reduced.
  • the vehicle systems preferably each comprise at least one control unit.
  • the diagnostic unit is integrated in a control unit of the vehicle, preferably in a central multi-function display operating system.
  • the vehicle data bus is a CAN bus and at least one of the diagnostic modules designed as a CAN snap module to log preselected CAN bus information.
  • a CAN snap module is a diagnostic module capable of logging preselected data transmitted via the vehicle data bus.
  • specifications can be made as to which data should be logged.
  • the logged data can be stored in a memory in the diagnostic framework to be available for later offline analysis. Therefore, in a preferred embodiment, a memory is provided in the diagnostic framework for storing therein the logged CAN bus information.
  • a development of the invention provides that the at least one configured as a CAN-snap module diagnostic module and / or at least one other of the diagnostic modules are configured to analyze the logged CAN bus information in terms of poor behavior or deviation from a good behavior in real time , As a result, error events can be detected, which are previously determined. Functional sequences can be monitored automatically in a targeted manner, in particular for complex processes, in order to determine causes of errors.
  • At least one of the diagnostic modules is configured to configure the CAN snap module corresponding to the error event when the error event is detected, the logged CAN bus information and / or an adjustable period of time for logging.
  • a vehicle 1 is shown.
  • the vehicle 1 includes a plurality of vehicle systems 2-14.
  • These vehicle systems 2-14 are configured as engine control unit 2, brake control unit 3, transmission control unit 4, comfort control unit 5, on-board control unit 6, door control unit 7, radio 8, navigation control unit 9, telematics control unit 10, control panel 11, further control units 12, 13 and as gateway 14.
  • To the gateway 14 are multiple vehicle data buses 15-19 linked.
  • the vehicle data buses 15-19 are designed as CAN drive data bus 15, CAN convenience data bus 16, CAN infotainment data bus 17, CAN combination data bus 18 and as CAN diagnostic data bus 19.
  • Connected to the CAN drive data bus 15 are the engine control unit 2, the brake control unit 3, the transmission control unit 4 and the further control unit 12.
  • the comfort control unit 5, the on-board power supply control unit 6, the door control unit 7 and the further control unit 13 are connected to the CAN comfort data bus 16.
  • the radio 8, the navigation control unit 9 and the telematics control unit 10 are connected to the CAN infotainment data bus 17.
  • Connected to the CAN combi data bus 18 is the switchboard 11 comprising a plurality of combination controls and display devices.
  • the CAN diagnostic data bus 19 is connected to a vehicle external test device 20.
  • a diagnostic framework 21 is provided. Between the diagnostic framework 21 and the individual vehicle data buses 15-19, one or more interfaces are provided in the gateway 14 (not shown). Individual diagnosis modules 22-26 are embedded in the diagnostic framework 21 or set up on the diagnostic framework 21.
  • the diagnostic modules 22-26 include a central diagnostic module 22, a system diagnostic module 23, a CAN snap diagnostic module 24, a telemetry data coordination diagnostic module 25, and a test module 26. These diagnostic modules 22-26 perform in-vehicle diagnostics of the vehicle systems 2-14. This means that the individual vehicle systems 2-14 do not include independent diagnostic modules.
  • the diagnosis is performed centrally by the diagnostic modules 22-26 in the diagnostic framework 21. As a result, the number of accesses indicated by lines 27 to the vehicle systems 2-13 is significantly reduced in number.
  • a diagnosis carried out by the vehicle-external test device 20 is carried out via the diagnostic framework, as indicated by the line 28.
  • the dotted lines 29, which indicates classical diagnostic accesses in a prior art embodiment, are not provided in the vehicle 1.
  • FIG. 2 is a further schematic representation of a vehicle 30 with a vehicle external test device 31 shown.
  • the vehicle 30 includes a diagnostic unit 32 configured as a gateway.
  • the diagnostic unit 32 includes a diagnostic framework 33, in which diagnostic modules 34 are integrated.
  • vehicle systems 36 are networked as control units via a vehicle data bus.
  • the diagnostic unit 32 and the vehicle-external test device 31 are networked with each other via a further vehicle data bus 37.
  • the vehicle systems 36 do not include diagnostic modules.
  • the diagnosis of the vehicle 30 is performed centrally by the diagnostic modules 34 in the diagnostic framework 33.
  • Individual external diagnostic modules 38 of the vehicle-external test device 31 access the central diagnostic framework 33 or the diagnostic modules 34 contained therein via a diagnostic application 39. Direct access of diagnostic modules of the vehicle external test device 31 to the vehicle systems 36 is not provided.
  • the diagnostic unit 40 comprises a memory 41 and an operating system software kernel 42.
  • the operating system software kernel 42 is set up by an operating system application program interface 43 (API).
  • the operating system application program interface 43 is again set up by a diagnostic framework 44, which represents an application program interface.
  • the diagnostic framework 44 uses portions of the memory 41. These portions of the memory 41 assigned to the diagnostic framework 44 are considered to be the memory of the diagnostic framework 44.
  • the diagnostic framework 44 further employs an interface 45.
  • the interface 45 includes a CAN application program interface 46, a CAN software kernel 47 and individual physical CAN interfaces 48.
  • the CAN software kernel 47 also employs Bandwidth allocation protocol 49 and an ISO transport protocol 50, which in turn a KWP-2000 protocol 51 touches.
  • Diagnostic modules 52-58 are based on diagnostic framework 44.
  • the diagnostic modules include a diagnostic module 52 that generates an error list, a CAN snap diagnostic module 53, a test module 54, a system diagnostic module 55, a telemetry data coordination diagnostic module 56, a function-oriented diagnostic module 57, and other diagnostic modules 58.
  • Via CAN data bus networking 59 the vehicle systems linked to the diagnostic unit 40.
  • a vehicle-external test device 61 is likewise connected to the diagnostic unit 40 via a diagnostic connector 60, data being exchanged by means of the KWP-2000 protocol.
  • the off-vehicle testing device 61 includes a system configuration coordinator 62, which is based on a communication coordinator 63.
  • the communication coordinator can access adapters 64 which access the diagnostic connector 60 or other transport protocols 67, including, for example, the TCP / IP protocol.
  • Fig. 4 Based on Fig. 4 will be explained how the CAN snap diagnostic module 53 after Fig. 3 Data of a CAN data bus is logged.
  • the binary signals "terminal 15", “terminal 50" and “KD-bit brake” are then plotted against time in each case. Underneath, the battery voltage and the speed are shown as graphs versus time.
  • the CAN snap module in this embodiment is configured to extract information concerning these listed signals from the data packets transmitted over the CAN data bus.
  • the individual signal values that are determined are each assigned a time stamp.
  • These data are stored in a memory. This may be a volatile memory for a timely evaluation or other storage medium in which the data is stored for a time-delayed diagnosis.
  • the graphs displayed can be produced from the data. Shown are the waveforms for a rolling a vehicle in front of a closed barrier.
  • the motor is switched off, which is indicated by a drop in the terminal 15 signal.
  • the terminal 15 is closed again and then the terminal 50 is closed (time C), causing a start of the engine.
  • the battery voltage signal 70 the battery voltage at time B decreases with the turning on of the terminal 15 (switching on the ignition). An even greater voltage drop occurs with the closing of terminal 50 (motor start).
  • the battery voltage signal 70 can be used to determine that the battery voltage is below a battery voltage threshold value 74 of 8 V for 250 ms.

Description

  • 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.
  • 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.
  • 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.
  • Die DE 10 2004 008 816 A offenbart eine Framework-Struktur zur Diagnose von Motordaten eines Fahrzeuges gemäß den Oberbegriff von Anspruch 1.
  • 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 beschleunigte 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.
  • 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.
  • Dabei werden einzelne übermittelte Daten der Fahrzeugsysteme zentral im Diagnoseframework vorgehalten, da diese häufig von mehreren Diagnosemodulen benötigt werden. Das Diagnoseframework hält einen Teil der von den Fahrzeugsystemen übermittelten Daten in einem Speicherbereich vor, um die Anzahl der Zugriffe der Diagnosemodule auf die Fahrzeugsysteme zu verringern.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
    • 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

Claims (13)

  1. Vorrichtung mit Diagnosefunktionalität in einem Fahrzeug (1) für eine Diagnose durch einen Fahrzeug-Datenbus (15-18; 35) vernetzter Fahrzeugsysteme (2-13; 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
    die Diagnoseeinheit mehrere Diagnosemodule (22-26; 34; 52-58) umfasst, die zum Ausführen der fahrzeuginternen Diagnose der einzelnen Fahrzeugsysteme (2-13; 36) ausgestaltet sind, und auf die Schnittstelle (45) ein Diagnoseframework (21; 33; 44) aufsetzt, das eine Anwendungsprogramm-Schnittstelle (API) für die mehreren Diagnosemodule (22-26; 34; 52-58) bereitstellt, wobei die 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 3, Zugriff der Diagnosemodule (22-26; 34; 52-58) auf die Fahrzeugsysteme (2-13; 36) koordiniert, wobei das Diagnoseframework (21; 33; 44) einen Teil der von den Fahrzeugsystemen (2-13; 36) übermittelten Daten in einem Speicherbereich vorhält, um die Anzahl der Zugriffe der Diagnosemodule (22-26; 34; 52-58) auf die Fahrzeugsysteme (2-13; 36) zu verringern.
  2. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass mindestens eines der Diagnosemodule (22-26; 34; 52-58) ausgestaltet ist, die Fahrzeugsysteme (2-13; 36) orientiert an Fahrzeugfunktionen zu analysieren.
  3. 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-13; 36) gemeinsam abgelegt sind.
  4. 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-13; 36) über das Diagnoseframework (21; 33; 44) erfolgt.
  5. 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.
  6. 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.
  7. 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.
  8. Vorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Fahrzeugsysteme (2-13; 36) Steuergeräte umfassen.
  9. 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.
  10. 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.
  11. 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.
  12. 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) ausgestattet sind, die protokollierten CAN-Businformationen in Echtzeit, insbesondere hinsichtlich eines Schlechtverhaltens und/oder einer Abweichung von einem Gutverhalten, zu analysieren.
  13. 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.
EP06090235A 2005-12-06 2006-11-27 Diagnosevorrichtungen in einem Fahrzeug mit Diagnoseframework für Diagnosemodule Not-in-force EP1796051B1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005058380 2005-12-06
DE102006009583A DE102006009583A1 (de) 2005-12-06 2006-02-28 Diagnosevorrichtung in einem Fahrzeug mit Diagnoseframework für Diagnosemodule

Publications (2)

Publication Number Publication Date
EP1796051A1 EP1796051A1 (de) 2007-06-13
EP1796051B1 true EP1796051B1 (de) 2009-02-11

Family

ID=37891739

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06090235A Not-in-force EP1796051B1 (de) 2005-12-06 2006-11-27 Diagnosevorrichtungen in einem Fahrzeug mit Diagnoseframework für Diagnosemodule

Country Status (3)

Country Link
EP (1) EP1796051B1 (de)
AT (1) ATE422694T1 (de)
DE (2) DE102006009583A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102010015132A1 (de) 2010-04-16 2011-10-20 Volkswagen Ag Datenerhebungsverfahren und Datenerhebungsvorrichtung für ein Fahrzeug

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007048087A1 (de) * 2007-10-05 2009-04-09 Volkswagen Ag Verfahren und Vorrichtung zur Ermittlung des Prüfumfanges bei der Fehlerdiagnose eines Kraftfahrzeuges
DE102009053753B4 (de) 2009-11-18 2017-03-30 Audi Ag Verfahren zum Ermitteln der Ursache eines Fehlers an einem Kraftfahrzeug
EP2653350A1 (de) * 2012-04-18 2013-10-23 Siemens Aktiengesellschaft Fahrzeugnetz
DE102012011908B4 (de) 2012-06-15 2018-02-22 Audi Ag Diagnosesystem für ein Kraftfahrzeug und Verfahren zum Betreiben eines solchen Diagnosesystems
CN102890502B (zh) * 2012-09-26 2016-07-06 芜湖伯特利汽车安全系统股份有限公司 一种防抱死制动系统控制器下线检测装置及检测方法
DE102013004070B3 (de) * 2013-03-11 2014-08-14 Audi Ag Verfahren zur Überprüfung eines Netzwerks und Netzwerkanordnung
DE102014207282A1 (de) 2014-04-16 2015-10-22 Volkswagen Aktiengesellschaft Verfahren zur Diagnose eines Kraftfahrzeugsystems, Diagnosegerät für ein Kraftfahrzeugsystem, Steuergerät für ein Kraftfahrzeugsystem und Kraftfahrzeug
DE102015002574B4 (de) 2015-02-27 2018-06-21 Audi Ag Kraftfahrzeug- Kommunikationsnetzwerk mit Switchvorrichtung
SE541395C2 (en) * 2017-12-27 2019-09-10 Scania Cv Ab Method and control unit for facilitating diagnosis for a vehicle

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5671141A (en) * 1993-04-05 1997-09-23 Ford Global Technologies, Inc. Computer program architecture for onboard vehicle diagnostic system
DE19731116A1 (de) * 1997-07-19 1999-01-28 Bosch Gmbh Robert Steuergerät für ein System und Verfahren zum Betrieb eines Steuergerätes
DE19836126A1 (de) * 1998-08-10 2000-02-24 Siemens Ag Steuergerät
DE19841267C1 (de) * 1998-09-09 2000-03-02 Siemens Ag Verfahren zur Durchführung einer Fehlerdiagnose und fahrzeugeigenes Fehlerdiagnosesystem
DE10000922A1 (de) * 2000-01-12 2001-07-19 Volkswagen Ag Elektronisches System
US6954689B2 (en) * 2001-03-16 2005-10-11 Cnh America Llc Method and apparatus for monitoring work vehicles
DE10145906A1 (de) * 2001-09-18 2003-04-10 Bosch Gmbh Robert Verfahren zur Durchfühung einer Ferndiagnose bei einem Kraftfahrzeug, Fahrzeugdiagnosemodul und Servicecenter
DE50301877D1 (de) * 2002-06-10 2006-01-12 Bosch Gmbh Robert Verfahren und vorrichtung für einen fahrzeugbezogenen telematikdienst
DE10307344B4 (de) * 2003-02-21 2005-09-29 Volkswagen Ag Vorrichtung und Verfahren zur dezentralen On-Board-Diagnose für Kraftfahrzeuge
US7263421B2 (en) * 2003-04-01 2007-08-28 Robert Bosch Gmbh Control unit for a restraint system
US7584029B2 (en) * 2003-12-31 2009-09-01 Teradyne, Inc. Telematics-based vehicle data acquisition architecture
DE102004008816A1 (de) * 2004-02-20 2005-09-08 Volkswagen Ag Verfahren und Vorrichtung zum Austauschen fahrzeugoriginärer Informationen

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102010015132A1 (de) 2010-04-16 2011-10-20 Volkswagen Ag Datenerhebungsverfahren und Datenerhebungsvorrichtung für ein Fahrzeug
DE102010015132B4 (de) 2010-04-16 2024-04-18 Volkswagen Ag Datenerhebungsverfahren und Datenerhebungsvorrichtung für ein Fahrzeug

Also Published As

Publication number Publication date
ATE422694T1 (de) 2009-02-15
EP1796051A1 (de) 2007-06-13
DE502006002803D1 (de) 2009-03-26
DE102006009583A1 (de) 2007-06-14

Similar Documents

Publication Publication Date Title
EP1796051B1 (de) Diagnosevorrichtungen in einem Fahrzeug mit Diagnoseframework für Diagnosemodule
DE102008015352B4 (de) Verfahren zum Aufzeichnen von Daten und Datenaufzeichnungssystem
EP1597643B1 (de) Vorrichtung und verfahren zur modellbasierten on-board-diagnose
EP1442277A1 (de) Verfahren zur durchführung einer ferndiagnose bei einem kraftfahrzeug, fahrzeugdiagnosemodul und servicecenter
DE4203704C2 (de) Verfahren zur Initialisierung eines elektronischen Regelsystems insbesondere in einem Kraftfahrzeug
DE3810239A1 (de) Multifunktionstester fuer die fehlerdiagnose
DE10313467A1 (de) Verfahren zur Fehlerdiagnose und dabei einsetzbarer Datenprotokollwandler
DE102005044236B4 (de) Diagnosegerät
DE102015108064B4 (de) Testsystem und Verfahren zum automatisierten Testen von wenigstens zwei gleichzeitig an das Testsystem angeschlossenen Steuergeräten sowie Steuergeräte-Anschluss- und Steuergeräte-Umschalteinheit zur Verwendung in einem solchen Testsystem
DE102010015132B4 (de) Datenerhebungsverfahren und Datenerhebungsvorrichtung für ein Fahrzeug
EP1315332A2 (de) Programmierbarer Datenlogger für CAN-Systeme
DE102007040216B4 (de) System zur Ansteuerung eines Rotorantriebes einer Offenend-Rotorspinnmaschine
EP3074782B1 (de) Vorrichtung und verfahren zum prüfen einer fahrzeugbatterie
EP1748360B1 (de) System und Verfahren zum Ausführen eines parallelisierten Softwareupdates
DE102013002648B3 (de) Master-Busgerät für einen Fahrzeugkommunikationsbus eines Kraftwagens
EP0437551B1 (de) Verfahren und vorrichtung zum abfragen von steuergeräte-daten
EP3132322B1 (de) Verfahren zur diagnose eines kraftfahrzeugsystems, diagnosegerät für ein kraftfahrzeugsystem, steuergerät für ein kraftfahrzeugsystem und kraftfahrzeug
DE102015003211A1 (de) Anordnung zur Diagnose eines Kraftfahrzeugs
EP2653350A1 (de) Fahrzeugnetz
DE10121587A1 (de) Verfahren und Vorrichtung zur automatisierten Prüfung grundlegender CAN-Eigenschaften von Steuergeräten
DE102012015783A1 (de) Diagnoseverfahren und Diagnosesystem für ein Kraftfahrzeug
DE102009034379A1 (de) Verfahren zum Übertragen von Daten
DE102006027550B3 (de) Verfahren zur Fehlerdiagnose eines datenbusvernetzten Systems und Diagnosesystem
DE102006002495A1 (de) Verfahren zum Speichern von Daten in einem Fahrzeug
DE102014017339A1 (de) Verfahren zum Ermitteln von Fehlerzuständen in einer Mehrzahl von Steuergeräten eines Kraftfahrzeugs

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

RIN1 Information on inventor provided before grant (corrected)

Inventor name: RUEB, GERNOT

Inventor name: BRAITSCHINK, PETER

Inventor name: BROSE, HEINO

17P Request for examination filed

Effective date: 20071213

17Q First examination report despatched

Effective date: 20080109

AKX Designation fees paid

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REF Corresponds to:

Ref document number: 502006002803

Country of ref document: DE

Date of ref document: 20090326

Kind code of ref document: P

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090522

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

NLV1 Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act
PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090611

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090511

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

REG Reference to a national code

Ref country code: IE

Ref legal event code: FD4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090713

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20091112

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090511

BERE Be: lapsed

Owner name: AUDI A.G.

Effective date: 20091130

Owner name: VOLKSWAGEN AG

Effective date: 20091130

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20091130

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20100730

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090512

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20091130

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20091130

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20091127

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20091127

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090812

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20101127

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101130

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101130

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101127

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20211130

Year of fee payment: 16

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 502006002803

Country of ref document: DE

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230529

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230601