WO2004104604A1 - Diagnosesystem - Google Patents

Diagnosesystem Download PDF

Info

Publication number
WO2004104604A1
WO2004104604A1 PCT/EP2004/004043 EP2004004043W WO2004104604A1 WO 2004104604 A1 WO2004104604 A1 WO 2004104604A1 EP 2004004043 W EP2004004043 W EP 2004004043W WO 2004104604 A1 WO2004104604 A1 WO 2004104604A1
Authority
WO
WIPO (PCT)
Prior art keywords
diagnostic
data
vehicle
server
telediagnostic
Prior art date
Application number
PCT/EP2004/004043
Other languages
English (en)
French (fr)
Inventor
Michael Engel
Ralf Keefer
Heinrich Kolster
Michael Müller
Ulrich Teufel
Original Assignee
Daimlerchrysler 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 Daimlerchrysler Ag filed Critical Daimlerchrysler Ag
Priority to US10/558,081 priority Critical patent/US20070100519A1/en
Publication of WO2004104604A1 publication Critical patent/WO2004104604A1/de

Links

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 diagnostic system in which a diagnostic program runs on an off-board diagnostic platform.
  • the diagnostic program accesses the control units of the technical system to be diagnosed via a radio-based communication interface.
  • the control units have a certain level of self-diagnosis.
  • a first, automatically generated diagnostic result can be expanded and completed as required via a user interface to the diagnostic platform.
  • German patent DE 195 23 483 C2 An example of a computer-based fault diagnosis device is contained in the German patent DE 195 23 483 C2.
  • This is a diagnostic program in which the impact chains are set up on the basis of a structural model and an impact model.
  • the technical system to be diagnosed is divided into subsystems and a knowledge base module is assigned to each subsystem.
  • an error model is generated from the knowledge base modules and the structural model, which contains and takes into account the error relationships of the individual subsystems.
  • the diagnostic program By evaluating the knowledge base modules and the structural model, the diagnostic program automatically determines which subsystems and which individual errors of a subsystem can contribute to the malfunction that has been identified. The diagnostic program then determines a decision tree for the malfunction identified, with which the fault responsible for the malfunction can be narrowed down.
  • the systems described above form, so to speak, the kernel, in technical terms also kernel, of a diagnostic system.
  • the diagnostic program works here with error codes which, as a mere code, are not necessarily understandable to a service technician. It has therefore been proposed in German patent application DE 197 25 915 AI to display the diagnostic results on a screen using a browser, such as is also used for websites.
  • the status information of the technical system to be diagnosed is prepared and displayed using a so-called markup language.
  • Known markup languages are e.g. B. HTML (Hyper Text Markup Language) or SGML (Standard Generalized Markup Language).
  • the invention is based on a diagnostic system for a motor vehicle, as was disclosed in the European patent application EP 10 87 343 AI.
  • the European patent application shows a diagnostic process in which a remote diagnosis for a vehicle is carried out with an expert system.
  • the diagnosis bus of the vehicle to be diagnosed is accessed from a diagnosis platform by means of a radio-based communication interface.
  • the error codes of the individual control units are read out via the communication interface and analyzed and evaluated by the expert system.
  • the data transmission from the vehicle to the expert system is preferably carried out via a mobile radio connection using the so-called SMS standard (SMS for Short Message Standard).
  • SMS Short Message Standard
  • vehicle identification is carried out first and then the data memories of the various control devices are read out and the data contents are transferred to the expert system. If no further data from the expert system If more are requested from the vehicle, the connection is automatically terminated.
  • the disadvantages of the above-mentioned remote diagnosis system lie, among other things, in the fact that all data are always read out from the control units.
  • the data contents to be transmitted in prior art diagnostic systems are in no way selected and specifically transmitted with regard to their relevance to faulty vehicle conditions. If previously known remote diagnosis systems with the transmitted data material do not come to a clear diagnosis result or to no diagnosis result, the diagnosis has failed. In the case of previously known systems, there is no possibility of influencing the diagnostic process and possibly requesting specific data.
  • the object of the invention is therefore to achieve an improved diagnosis result with the least possible communication effort.
  • the solution is mainly successful with a diagnostic system that can download the results of the on-board system diagnosis in the vehicle itself using a radio-based communication interface and evaluate it on an off-board diagnostic platform.
  • the diagnostic process can be intervened via a user interface in a customer assistance center and the diagnostic result can be expanded as required.
  • the on-board system diagnosis collects vehicle data by listening to the buses to which the control units are connected for errors. These errors are processed and stored in a memory with relevant status information. information about the control units.
  • a diagnostic computer in the vehicle or a bus master can collect this information at fixed intervals and store it in a ring buffer. After the telediagnosis has been drawn, the most meaningful data is packed into an SMS and sent to the diagnosis center in the Customer Assistance Center (SMS for short message standard in mobile communications).
  • SMS Customer Assistance Center
  • the data is then evaluated in the Customer Assistance Center on a central diagnostic platform with a complex diagnostic program.
  • the diagnostic program is essentially a complex software algorithm.
  • the diagnostic program enables conclusions to be drawn about the cause of the error. If additional vehicle data are required, these can be requested later. The additional data can either be triggered manually by a technician in the Customer Assistance Center or automatically by the diagnostic program. With the requested data, the diagnostic program is continued and the analysis result is improved.
  • the data request is based on a complex process that evaluates the data already received.
  • the requested data is packed into one or more SMS and sent to the head office.
  • the data can be requested any number of times.
  • the data request is based on a freely usable or adjustable configuration file, which is evaluated at the time of the telediagnosis.
  • the analysis results of the diagnostic program are converted from the vehicle-specific data format that the control units use to an XML meta format and saved.
  • the diagnostic system on the central diagnostic platform contains a central thesaurus. Using the central thesaurus, the data and analysis results of the diagnostic program can be processed for a web browser and displayed in various national or national languages.
  • the diagnostic system or the diagnostic method contains a data completer. The data completer evaluates the initial data packet transmitted by SMS and supplements the transmitted data with series-specific information about the technical system or vehicle to be analyzed if required, by automatically requesting further data relevant to the error that has occurred from the system to be analyzed.
  • the data exchange between the vehicle and the central diagnostic platform takes place via an interposed fleet server, e.g. via a fleet board server.
  • fleet board servers are mainly used in commercial heavy goods vehicles by transport and logistics companies to control and maintain the vehicle fleet. Therefore, these fleet board servers contain additional information about maintenance intervals of the vehicles, location of the vehicles, repairs carried out, upcoming inspections etc. It is therefore advantageous, if fleet board servers exist, to include this information in the diagnostic result in order to include a to get an improved diagnostic result. In this way, inspections that quickly become obsolete can be filtered out and processed together with the current error that has occurred. This saves the vehicle from having to visit the workshop for the transport company.
  • the solutions described above try to keep data communication between the vehicle and the control center as low as possible. This reduces the likelihood of losing data packets during the transmission process or of receiving the data packets too late in the event of network congestion for the central diagnostic program to run properly.
  • the wide not only pure status data is transmitted, but also information about faulty components in the vehicle (e.g. lamp, seat, fuel injector, etc.) and error codes from the control units.
  • the data request offers the possibility to request current data from the vehicle after interaction with the customer and thus to improve the analysis result.
  • the telediagnostic system is based on existing central diagnostic platforms and existing on-board diagnostic systems installed in the vehicle. This means that the telediagnostic system can be loaded using existing diagnostic programs and diagnostic systems.
  • the diagnostic results generated can be displayed in different national languages. This has the advantage that the technician in the Customer Assistance Center can choose his mother tongue when performing the diagnosis.
  • the diagnostic result can also be translated in the vehicle driver's mother tongue and transferred to the in-vehicle tools.
  • XML data structures has the advantage that diagnostic results from the data used formats of off-board systems and on-board systems, which often work with non-transparent error codes, become independent.
  • Web-based applications can also be implemented with the XML data format.
  • the diagnosis results obtained in the Customer Assistance Center can be forwarded to any workshop connected to the Internet and viewed by the service technician in the workshop via Internet connections or intranet connections.
  • the diagnosis specialist in the Customer Assistance Center and the service technician in the workshop always have the same up-to-date information in mind and can, if necessary, provide advice on a telephone line.
  • FIG. 1 shows a layer model for the telediagnostic system with the associated modules
  • FIG. 3 shows a possible server structure for the telediagnostic system in the customer assistance center
  • FIG. 5 shows a block diagram of a service assistant server
  • Fig. 7 is a screen shot of the telediagnostic viewer in the Customer Assistance Center.
  • a telediagnostic system in the form of a data processing system is provided. which can process and display the telediagnostic data from different series.
  • a diagnostic program is implemented in the Customer Assistance Center on a central data processing platform.
  • the diagnostic program has a connection to a central diagnostic database in which diagnostic-relevant information about the structure of the vehicles to be diagnosed, past experience as well as identifiers for identifying the vehicles and the control units are stored in the vehicle itself.
  • the diagnostic program has a communication interface to the servers in the Custom Assistant Center.
  • the telediagnostic data are read into the diagnostic system on the input side via a radio-based communication interface 1.
  • the radio-based communication interface is based on the known standards for mobile radio, in particular on the data transmission formats known under GSM and SMS (SMS for Short Message Service).
  • GSM Global System for Mobile Communications
  • SMS Short Message Service
  • the telediagnostic system has a central communication platform Telematic Services Kernel (TS Kernel) and a customer database TSDB.
  • TS Kernel Telematic Services Kernel
  • TSDB customer database
  • the communication platform carries out an authorization query for the incoming calls from the vehicles. This essentially checks whether the requesting vehicle is registered in the customer database TSDB.
  • the vehicle identification number FIN is used to identify the vehicle.
  • Another task of the central communication platform is to determine the current position of the vehicle using the GPS data transmitted by the mobile radio.
  • digital land and street maps are also stored in the customer database TSDB, with the aid of which the communication platform TS kernel determines the position of the vehicle and counteracts it. If necessary, the nearest service station to the vehicle in which the vehicle can be repaired is determined.
  • the scope of the diagnostic data available which can be transferred from the on-board system in the vehicle to the telediagnostic system in the Customer Assistance Center, includes the following data:
  • Status information about status values of the vehicle such as B. Battery voltage, ignition position, position data, mileage, tank filling and vehicle identification (VIN). This data is transmitted in an initial TD message as an initial data packet.
  • the initial data packet “Initial TD Message” initially transmits basic data from the vehicle to the telediagnostic system in the Customer Assistance Center.
  • the further information blocks mentioned above can be obtained from the on-board system of the motor vehicle upon request and read out as required and transferred from the vehicle to the telediagnostic system.
  • the data exchange is sent via a centrally installed fleet board server, which is preferably used by the transport and logistics companies.
  • the status and identification of the vehicle, position data, telephone number and language of the driver, date and time, as well as information about the vehicle's condition, including the control unit error code, are transmitted.
  • the Fleet Board Server also provides access to the vehicle's current maintenance data.
  • the communication platform TS-Kernel has two further interfaces for the communication connection in the Customer Assistance Center.
  • the TS kernel is connected to a so-called Service Assistant Server SAS server in the computer network of the call center via a server interface SAS interface.
  • the TS kernel is connected to the computer network for the screen workstations in the call center in the Customer Assistance Center Local Area Network CAC-LAN via a possible second CSR interface.
  • the employees in the call center the so-called Customer Service Representatives CSR, can influence the communication process in the TS kernel. In particular, they can request specific data via the CSR interface.
  • the Service Assistant Server SAS server the transmitted diagnostic data are processed and displayed to the employees in the call center via a human-machine interface MMI in the form of a telediagnostic viewer.
  • the service assistant server in the call center mainly comprises the following modules for data preparation:
  • a data converter that uses a converter configuration to configure the various data protocols which board networks of passenger cars and lorries can be used, converted into a uniform data format, in particular into an XML structure.
  • a data completer who uses a completer configuration to read out series-specific data requests from the vehicle to be diagnosed via a request to the SAS interface via the diagnostic program.
  • the completed data is displayed on the MMI telediagnostic viewer.
  • the DV-supported systems for the Service Assistant Server for the actual diagnostic program and for the workstation computers in the local area network of the call center are based on the Windows NT4 operating system.
  • the TCP / IP protocol is the standard data connection between the systems.
  • a Unix / Linux-based system can also be a suitable alternative.
  • the performance of the telediagnostic system takes into account the real-time requirements of the diagnostic process to enable real-time contact between the call center employee and a service technician in the workshop. This also includes the ability to diagnose several vehicles at the same time.
  • FIG. 2 gives a process overview of the processes running on the Service Assistant Server SAS server.
  • the central element for the communication between the different processes is a Telematic Services Identifier (TSID), which is assigned to an incoming call from a motor vehicle by the central communication platform TS Kernel.
  • TSID Telematic Services Identifier
  • the various sub-processes are synchronized by means of the fault detection and the results of the different sub-processes are clearly assigned to a current diagnostic process.
  • the Vehicle incoming initial data packet in the TS kernel subjected to an authorization check.
  • the interface to the SAS server is initialized and the first initial data packet is analyzed in the SAS server and an automatic data completion is carried out using logic.
  • This prepared first diagnostic result is prepared in text form with a thesaurus and displayed on a telediagnostic viewer.
  • the telediagnostic viewer is used for the visualization of the diagnostic result and also for further control if a further diagnostic process is required.
  • the automatic data completion is carried out by means of a completer configuration, which is essentially a conversion table, in which it is recorded which series-specific data should also be integrated in the diagnostic process, taking into account the current vehicle condition, ie which later dynamic data (e.g. error codes the control units), which can provide conclusions about the existing error, should be requested.
  • the series-specific data are symbolized by the provision of data.
  • the employees in the call center can obtain further information and control the further course of the diagnostic process.
  • the incoming call is assigned to an employee (CSR for Customer Service Representative) in the call center for processing in the entire diagnostic process together with the TSID error code via an automatic distributor (dispatcher) together with the error code.
  • the incoming calls can be assigned to the employees in the call center according to the qualifications of the employees. So can z.
  • a fault in the engine control unit can be specifically directed to a specialist for engine control units or a fault in the anti-lock braking system can be specifically forwarded to a specialist for anti-lock braking systems.
  • Figure 3 illustrates the minimum requirements for the network structure in the call center.
  • a Customer Assistance Center Local Area Network CAC-LAN several DV platforms CSR workstations are connected as SAS clients to the SAS server and to the TS server.
  • the SAS server is the previously mentioned Service Assistant Server, while the TS server is the DV platform for the diagnostic program.
  • the TS server and the SAS server communicate here via the SAS interface or via the TS kernel interface and with the SAS clients.
  • the connection of the SAS clients via a Local Area Network offers the possibility of accessing the results of the telediagnosis, which are created by the TS server and SAS server, from different workstations and on the workstations using a telediagnostics viewer to display.
  • FIG. 4 again illustrates the integration of the Service Assistant Server SAS in the telediagnostic system.
  • the initiation of the telediagnostic process takes place on the vehicle side either by the driver of the vehicle or by automatic drawing by the on-board diagnostic system on the vehicle side.
  • the driver initiates the telediagnostic process, for example, by pressing a special button in the vehicle with which the telediagnostic process can be triggered. If the tele-diagnosis process is triggered automatically by the vehicle's on-board diagnosis system, the tele-diagnosis process is triggered by the occurrence and detection of an error in the vehicle itself.
  • the on-board data are updated in the control units of the vehicle or in the fault memory of the on-board diagnostic system and a data connection to the TS kernel is established.
  • An initial data packet consisting of a vehicle identification FIN, a digital time stamp and digital error information, is sent to the TS kernel via the communication interface.
  • the TS kernel checks the access authorization to the telediagnostic system and saves the initial data packet in the form of a data object.
  • This data object receives an error identifier TSID as an identifier.
  • the incoming call from the vehicle triggers a trigger mechanism for the telediagnostic system in the TS kernel.
  • the interfaces from the TS kernel to the Customer Assistance Center Local Area Network CAC-LAN and to the Service Assistant Server SAS are initialized and activated. Furthermore, the incoming call is assigned to an employee CSR in the call center via a dispatcher. The data flow is controlled via the TSID error detection.
  • a call arriving from the motor vehicle triggers a trigger mechanism for the Service Assistant Server SAS in the central communication platform TS kernel.
  • the initial data packet from the on-board diagnostic system of the motor vehicle is transferred from the TS kernel to the Service Assistant Server SAS.
  • these data and all other telediagnostic data to be exchanged are converted into an XML data structure common to all series of the motor vehicle.
  • the converted data is implemented by software implemented logic interpreted in the program module data completer.
  • those data blocks are determined which can provide additional information about error states. These are e.g. B.
  • Service data Operating values, status of the on-board system diagnosis in the motor vehicle, control unit error codes, etc.
  • These data packets which can be called up from the vehicle and provide additional information on the fault conditions, are automatically sent by the data completer via request to the TS Kernel transmitted and requested and read by the TS kernel from the vehicle via the communication interface.
  • the status of the on-board system diagnosis in the motor vehicle is requested, received, converted and interpreted.
  • the diagnostic data for example the error codes for the control unit in question, are requested and transmitted.
  • the incoming data is in turn converted and saved by the data converter module in an XML structure that is the same for all series.
  • the bits and bytes of the raw data are replaced by the appropriate thesaurus indices, which represent the textual description of the information.
  • the thesaurus texts which have already been assigned to the determined error codes, are used to display the thesaurus texts.
  • the thesaurus texts are generally understandable error texts and contain in particular the names of the diagnosed components.
  • the employee in the call center can select the language in which the texts are to be displayed by selecting a suitable thesaurus. This allows the employee in the call center to view the diagnostic results e.g. B. display in English by default or choose your mother tongue to display the diagnostic results.
  • the data converter has the task of generating a vehicle-independent XML data structure from raw data.
  • the conversion rule for each series of a motor vehicle is obtained from a series-specific converter configuration.
  • the file name for the converted diagnostic result is generated automatically and is made up of the error identifier TSID and a digital time stamp. For example, ten fixed places in the file name are reserved for the error identifier TSID. After the fault has been identified, there is a time stamp that contains information about the year, month, day and hours, minutes and seconds.
  • the data completer processes the XML data structure generated by the data converter.
  • the data completer has a logic set for the series via the predecessor configuration.
  • the telediagnostic data in the XML data structure are evaluated with this logic. Necessary additional data requirements for the vehicle are determined based on the available data and the configuration.
  • the requests for the subsequent data request to the vehicle are formulated and issued via the TS kernel.
  • the initial data packet contains vehicle basic data, such as.
  • a list is transmitted with the initial data packet, in which control devices are marked as defective by the on-board diagnosis.
  • the data completer analyzes the data from the initial data ket, which was converted into an XML file by the data converter.
  • the control devices marked as defective in the initial data packet lead, after analysis by the data completer, to a subsequent data request, in which further data, e.g. B. the status block of the control unit and the error codes can be read out.
  • the diagnostic program on which the telediagnostic system is based is a model-based diagnostic program
  • further environmental data are also read out from the motor vehicle, which can describe the error that has occurred more precisely.
  • These environmental data are e.g. B. the status data of the neighboring control units in the hierarchy of the control unit diagnosed as defective.
  • all vehicle data can also be requested.
  • the request for data is also transmitted via the radio-based communication interface, that is to say via mobile radio and in this case preferably via the SMS standard.
  • the evaluation logic for the data request is designed to be configurable. This allows the transmitted data packets to be adapted to the series-specific features of the motor vehicles.
  • the configuration is recorded in an XML file and is referred to in FIG. 5 as a completer configuration.
  • the information of the completer configuration is read anew with each new call and thus determined with which further data request the telediagnostic system reacts to the previously received initial data packet.
  • the predecessor configuration is specific to the series and can be adapted accordingly if there are changes in the series of the motor vehicles. If the diagnostic program does not come to a satisfactory diagnostic result with the requested data, then in addition to the automatically triggered data request already described, there is also the possibility of the data request by the Call center staff.
  • the previous diagnosis result is displayed on the telediagnostic viewer.
  • the employee in the call center can now assess the previous diagnostic result.
  • the employee in the diagnostic center can specifically request and read out further status data of the motor vehicle via the diagnostic program.
  • the call center employee can also use a telephone connection to ask the driver of the motor vehicle about the error symptoms that occur in the motor vehicle.
  • the visualization of the diagnostic result on the telediagnostic viewer is discussed in more detail below.
  • the data must first be linked to the corresponding thesaurus texts via a "integration of the thesaurus" process.
  • the linker takes over the integration of the thesaurus.
  • Tables for interpreting the data sent by the vehicle error codes and others
  • This also includes control tables for identifying the control unit variants installed in the vehicle.
  • the control unit variants installed generally vary from one series to the next.
  • the installed control units are identified by the on-board diagnostic system, for example using the network addresses or other control device data of the control devices. These network addresses are preferably so-called CAN identifiers.
  • SMS data packets arriving from the vehicle are analyzed and, as explained in connection with FIG. 5, a processed and structured diagnostic result is generated in the form of telediagnostic data.
  • the error text relevant for this diagnostic result is selected and linked to the diagnostic result via the error code of the diagnostic result and the thesaurus indices that reference these error codes.
  • This structured diagnostic result generated in this way is either displayed or temporarily stored as a vehicle output file on a storage medium of the Service Assistant server.
  • FIG. 7 finally shows a visualization of the diagnosis result generated with the previously described telediagnostic system and the previously described telediagnosed method on the telediagnosed viewer.
  • the vehicle condition provides information about the errors that have occurred.
  • a defect was found in the electronic stability program ESP, which was indicated in the instrument cluster by a flashing ESP info lamp.
  • the cause of the flashing ESP info lamp was identified by the telediagnostic system as two possible causes of the error.
  • the causes of the error are displayed with the error code and the thesaurus text assigned to this error code.
  • the errors relating to the airbag safety system which were also ascertained, cannot easily be perceived by the vehicle driver. Two errors were found in the airbags.
  • the line to the belt buckle at the front left has a short circuit and, on the other hand, at least one airbag in the rear of the vehicle was not correctly coded, ie the programming of the connected peripherals in the airbag control unit must be checked.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Vehicle Cleaning, Maintenance, Repair, Refitting, And Outriggers (AREA)

Abstract

Die Erfindung betrifft ein Diagnosesystem, das sich mittels einer funkbasierten Kommunikationsschnittstelle die Ergebnisse der On-Board-Systemdiagnose im Fahrzeug selbst herunterladen kann und auf einer Off-Board-Diagnoseplattform auswertet. Die On-Board-Diagnose sammelt hierbei Fahrzeugdaten, indem sie die Busse, an denen die Steuergeräte angeschlossen sind, nach Fehlern abhört. Diese Fehler werden aufbereitet und in einem Speicher mit relevanten Zustandsinformationen über die Steuergeräte abgelegt. Ein Diagnoserechner kann sich in festgelegten Zeitabständen diese Informationen abholen und sie in einem Ringpuffer ablegen. Nach Auslösung der Telediagnose werden die aussagekräftigsten Daten an die Diagnosezentrale im Customer Assistance Center geschickt. Die Datenauswertung erfolgt dann im Customer Assistance Center auf einer zentralen Diagnoseplattform mit einem komplexen Diagnoseprogramm. Mit dem Diagnoseprogramm werden Rückschlüsse auf die Fehlerursache gezogen. Falls dazu zusätzliche Fahrzeugdaten nötig sind, können diese nachgefordert werden. Mit den nachgeforderten Daten wird das Diagnoseprogramm fortgesetzt und das Analyseergebnis verbessert. Die nachgeforderten Daten werden an die Zentrale geschickt. Die Datennachforderung kann beliebig oft erfolgen. Die Datennachforderung beruht auf einer frei bedatbaren bzw. einstellbaren Konfigurationsdatei, welche zur Laufzeit der Telediagnose ausgewertet wird. Die Analyseergebnisse des Diagnoseprogramms werden aus dem fahrzeugspezifischen Datenformat, das die Steuergeräte verwenden, in ein XML-Metaformat gewandelt und gespeichert.

Description

DiagnoseSystem
Die Erfindung betrifft ein Diagnosesystem, bei dem auf einer Off-Board-Diagnoseplattform ein Diagnoseprogramm ablauft. Das Diagnoseprogramm greift über eine funkbasierte Kommunikationsschnittstelle auf die Steuergerate des zu diagnostizierenden technischen Systems zu. Die Steuergerate verfugen hierbei über eine gewisse Eigendiagnosefahigkeit . Über eine Anwenderschnittstelle zur Diagnoseplattform kann ein erstes, automatisch erzeugtes Diagnoseergebnis bedarfsgesteuert erweitert und vervollständigt werden.
Technologischer Hintergrund für die hier offenbarte Erfindung bilden die deutsche Patentanmeldung DE 197 25 915 AI und die deutsche Patentschrift DE 41 06 717 Cl. Bei diesen vorbekannten Diagnosesystemen können Funktionsstörungen von Steuergeraten in einem Kraftfahrzeug erkannt werden. Die Funktionsstörung der einzelnen Steuergerate wird hierbei in Datenpaketen festgehalten und in einem Netzwerk kommuniziert. Das Diagnoseprogramm analysiert die kommunizierten Datenworte und grenzt die für die Funktionsstörung verantwortlichen Fehlerquellen mittels eines automatisch ablaufenden Prüfalgonthmus ein. Es handelt sich hierbei um eine sogenannte modellbasier- te Diagnose. Kennzeichen einer modellbasierten Diagnose ist die Kenntnis der Wirkungsketten der einzelnen Steuergerate im technischen Gesamtsystem. Diese Wirkungsketten enthalten alle Fehlerquellen, die als Fehlerursache für Funktionsstörungen in Frage kommen können. Anhand von auf die Wirkungsketten abgestimmten Prüfschritten wird die Wirkungskette vollständig überprüft und der Fehler im Gesamtsystem eingegrenzt. Ein Beispiel für eine rechnergestutzte Fehlerdiagnoseeinrichtung ist in der deutschen Patentschrift DE 195 23 483 C2 enthalten. Hierbei handelt es sich um ein Diagnoseprogramm, bei dem die Wirkungsketten anhand eines Strukturmodells und eines Wirkungsmodells aufgestellt werden. Hierbei ist das zu diagnostizierende technische System in Teilsysteme aufgegliedert und jedem Teilsystem ist ein Wissensbasismodul zugeordnet. Aus den Wissensbasismodulen und dem Strukturmodell wird schließlich ein Fehlermodell erzeugt, das die Fehlerzusammenhange der einzelnen Teilsysteme enthalt und berücksichtigt. Durch Auswertung der Wissensbasismodule und des Strukturmodells wird von dem Diagnoseprogramm automatisch ermittelt, welche Teilsysteme und welche einzelnen Fehler eines Teilsystems zu der festgestellten Fehlfunktion beitragen können. Das Diagnoseprogramm ermittelt daraufhin zu der festgestellten Funktionsstörung einen Entscheidungsbaum, mit dem der für die Funktionsstörung verantwortliche Fehler eingegrenzt werden kann.
Die vorbeschriebenen Systeme bilden gewissermaßen den Kern, in der Fachsprache auch Kernel, eines Diagnosesystems. Das Diagnoseprogramm arbeitet hier mit Fehlercodes, die als bloßer Code einem Service-Techniker nicht unbedingt verstandlich sind. Man hat deshalb in der deutschen Patentanmeldung DE 197 25 915 AI vorgeschlagen, die Diagnoseergebnisse auf einem Bildschirm mittels einem Browser, wie er auch für Internetseiten eingesetzt wird, darzustellen. Die Statusinformationen des zu diagnostizierenden technischen Systems werden hierbei mit einer sogenannten Markup-Language aufbereitet und zur Anzeige gebracht. Bekannte Markup-Languages sind z. B. HTML (Hyper Text Markup Language) oder SGML (Standard Generalized Markup Language) .
Aufbauend auf diesem technologischen Hintergrund hat man inzwischen ein Dokumentenverwaltungssystem für Diagnosedaten eingeführt, das auf dem XML-Standard basiert (XML für Stan- dard extended Markup Language) . Eine kurze Beschreibung dieses XML-Dokumentenverwaltungssystems für Diagnosedaten findet sich in der Pressemitteilung der Software AG aus Darmstadt vom 10. Oktober 2002: „Workflow-gestutzte XML-Dokumentenverwaltung für Diagnosedaten in Entwicklung, Produktion und Service" . Bei diesem Dokumentenverwaltungssystem können für jedes Steuergerat auf einem Server verschiedene Dokumententypen hinterlegt werden und auf Basis des XML-Standards mit einem Marker für die Fahrzeugversion oder die Steuergerateversion versionssicher verknüpft werden. Beispiele für die verschiedenen Dokumententypen zu jedem Steuergerat im Kraftfahrzeug sind Steuergeratespezifikationen, Testergebnisse und ergänzende textuelle Informationen sowie Graphiken und Bilder. Das Dokumentenverwaltungssystem bietet hierbei die Möglichkeit für den Benutzer, den Zugriff auf bestimmte Steuergerate und auf bestimmte Dokumente als sogenannter Schnellzugriff selbst zu definieren.
Nach dem Vorgesagten geht die Erfindung aus von einem Diagnosesystem für ein Kraftfahrzeug, wie es in der europaischen Patentanmeldung EP 10 87 343 AI offenbart wurde. Die europaische Patentanmeldung zeigt einen Diagnoseprozess, bei dem mit einem Expertensystem eine Ferndiagnose für ein Fahrzeug durchgeführt wird. Von einer Diagnoseplattform aus, wird mittels einer funkbasierten Kommunikationsschnittstelle auf den Diagnose-Bus des zu diagnostizierenden Fahrzeugs zugegriffen. Über die Kommunikationsschnittstelle werden die Fehlercodes der einzelnen Steuergerate ausgelesen und von dem Expertensystem analysiert und ausgewertet. Die Datenübertragung vom Fahrzeug zum Expertensystem erfolgt hierbei vorzugsweise über eine Mobilfunkverbindung mittels des sogenannten SMS- Standards (SMS für Short Message Standard) . Nach erfolgtem Verbindungsaufbau zwischen Expertensystem und Fahrzeug wird zunächst eine Fahrzeugidentifikation durchgeführt und anschließend werden die Datenspeicher der verschiedenen Steuergerate ausgelesen und die Dateninhalte an das Expertensystem übertragen. Wenn von dem Expertensystem keine weiteren Daten mehr aus dem Fahrzeug angefordert werden, wird die Verbindung automatisch abgebrochen.
Die Nachteile des vorgenannten Ferndiagnosesystems liegen unter anderem darin begründet, dass stets alle Daten aus den Steuergeraten ausgelesen werden. Insbesondere werden die zu übermittelnden Dateninhalte bei vorbekannten Diagnosesystemen in keiner Weise hinsichtlich der Relevanz auf fehlerhafte Fahrzeugzustande ausgesucht und speziell übertragen. Kommen vorbekannte Ferndiagnosesysteme mit dem übertragenen Datenmaterial zu keinem eindeutigen Diagnoseergebnis oder zu keinem Diagnoseergebnis so ist die Diagnose gescheitert. Eine Möglichkeit, auf den Diagnoseablauf einzuwirken und evtl. gezielt Daten nachzufordern, besteht bei vorbekannten Systemen nicht.
Erfindungsgemaße Aufgabe ist es daher, mit einem möglichst geringen Kommunikationsaufwand zu einem verbesserten Diagnoseergebnis zu gelangen.
Die Aufgabe wird gelost mit einem Diagnosesystem oder einem Diagnoseverfahren, jeweils mit den Merkmalen der zugehörigen unabhängigen Ansprüche. Vorteilhafte Ausgestaltungen der Erfindung finden sich in den Unteranspruchen und in der Beschreibung.
Die Losung gelingt hauptsachlich mit einem Diagnosesystem, das sich mittels einer funkbasierten Kommunikat onsschnitt- stelle die Ergebnisse der On-Board-Systemdiagnose im Fahrzeug selbst herunterladen kann und auf einer Off-Board- Diagnoseplattform auswertet. Über eine Bedienschnittstelle in einem Customer Assistance Center kann in den Diagnoseablauf eingegriffen werden und das Diagnoseergebnis bedarfsgesteuert erweitert werden. Die On-Board-Systemdiagnose sammelt hierbei Fahrzeugdaten, indem sie die Busse, an denen die Steuergerate angeschlossen sind, nach Fehlern abhört. Diese Fehler werden aufbereitet und in einem Speicher mit relevanten Zustandsin- formationen über die Steuergerate abgelegt. Ein Diagnoserechner im Fahrzeug oder ein Bus-Master kann sich in festgelegten Zeitabstanden diese Informationen abholen und sie in einem Ringpuffer ablegen. Nach Auslosung der Telediagnose werden die aussagekraftigsten Daten in eine SMS gepackt und an die Diagnosezentrale im Customer Assistance Center geschickt (SMS für Short Message Standard im Mobilfunk) . Die Datenauswertung erfolgt dann im Customer Assistance Center auf einer zentralen Diagnoseplattform mit einem komplexen Diagnoseprogramm. Das Diagnoseprogramm ist hierbei im Wesentlichen ein komplexer Software-Algorithmus. Mit dem Diagnoseprogramm werden Rückschlüsse auf die Fehlerursache gezogen. Falls dazu zusatzliche Fahrzeugdaten notig sind, können diese nachgefordert werden. Die Datennachforderung kann hierbei entweder manuell von einem Techniker im Customer Assistance Center oder selbsttätig von dem Diagnoseprogramm ausgelost werden. Mit den nachgeforderten Daten wird das Diagnoseprogramm fortgesetzt und das Analyseergebnis verbessert. Die Datennachforderung basiert auf einem komplexen Verfahren, welches die bereits erhaltenen Daten auswertet. Die nachgeforderten Daten werden in eine oder mehrere SMS gepackt und an die Zentrale geschickt. Die Datennachforderung kann beliebig oft erfolgen. Die Datennachforderung beruht auf einer frei bedatbaren bzw. einstellbaren Konfigurationsdatei, welche zur Laufzeit der Telediagnose ausgewertet wird. Die Analyseergebnisse des Diagnoseprogramms werden aus dem fahrzeugspezifischen Datenformat, das die Steuergerate verwenden, in ein XML-Metaformat gewandelt und gespeichert.
In einer Weiterbildung der Erfindung enthalt das Diagnosesystem auf der zentralen Diagnoseplattform einen zentralen Thesaurus. Unter Nutzung des zentralen Thesaurus können die Daten und Analyseergebnisse des Diagnoseprogramms für einen Web-Browser aufgearbeitet werden und in verschiedenen Landessprachen oder Nationalsprachen zur Anzeige gebracht werden. In einer vorteilhaften Ausgestaltung der Erfindung enthalt das Diagnosesystem oder das Diagnoseverfahren einen Datenver- vollstandiger . Der Datenvervollstandiger wertet das per SMS übertragene initiale Datenpaket aus und ergänzt die übertragenen Daten bei Bedarf mit baureihenspezifischen Informationen zu dem zu analysierenden technischen System oder Fahrzeug, indem er automatisch die für den aufgetretenen Fehler relevanten weiteren Daten von dem zu analysierenden System nachfordert .
In einer alternativen Ausfuhrung der Erfindung erfolgt der Datenaustausch zwischen Fahrzeug und zentraler Diagnoseplattform über einen zwischengeschalteten Flottenserver z.B. über einen Fleet-Board-Server. Fleet-Board-Server werden hauptsachlich im kommerziellen Schwerlastverkehr bei Transport- und Logistikunternehmen zur Steuerung und Wartung des Fuhrparks eingesetzt. Daher enthalten diese Fleet-Board-Server zusatzliche Informationen über Wartungsintervalle der Fahrzeuge, Standort der Fahrzeuge, durchgeführte Reparaturen, anstehende Inspektionen usw. Es ist daher vorteilhaft, bei E- xistenz von Fleet-Board-Servern diese Informationen in das Diagnoseergebnis einzubeziehen, um ein verbessertes Diagnoseergebnis zu erhalten. Auch können auf diese Weise in Kurze fallig werdende Inspektionen herausgefiltert werden und zusammen mit dem aktuellen, aufgetretenen Fehler abgearbeitet werden. Für das Transportunternehmen kann auf diese Weise ein Werkstattaufenthalt des Fahrzeugs eingespart werden.
Mit der Erfindung werden hauptsachlich die folgenden Vorteile erzielt :
Die oben beschriebenen Losungen versuchen die Datenkommunikation zwischen Fahrzeug und Zentrale möglichst gering zu halten. Damit reduziert sich die Wahrscheinlichkeit, beim Uber- tragungsprozess Datenpakete zu verlieren oder bei Netzuber- lastung die Datenpakete zu spat für einen ordnungsgemäßen Ablauf des zentralen Diagnoseprogramms zu erhalten. Des Weite- ren werden nicht nur reine Zustandsdaten übertragen, sondern bereits Informationen über fehlerhafte Komponenten im Fahrzeug (z. B. Lampe, Sitz, Einspritzventil usw.) sowie Fehlercodes der Steuergerate mitubertragen. Die Datennachforderung bietet die Möglichkeit, nach Interaktion mit dem Kunden aktuelle Daten vom Fahrzeug nachzufordern und somit das Analyseergebnis zu verbessern.
Ein weiterer Vorteil wird darin gesehen, dass ein Mitarbeiter im Customer Assistance Center bei einem Diagnoseablauf immer den aktuellen Zustand des Fahrzeugs abfragen kann und sich auf einem Telediagnose-Viewer anzeigen lassen kann. Hierdurch kann stets ein aktuelles Diagnoseergebnis generiert werden und der Fahrzeugfuhrer kann stets mit einer aktuellen Hand- lungsanweisung beraten werden. Diese Handlungsanweisung kann z. B. in dem Rat bestehen, die nächste Werkstatt aufzusuchen oder bei weniger gravierenden Fehlern, zunächst weiterzufahren und bei nächster Gelegenheit den Fehler beheben zu lassen .
Ein weiterer Vorteil des Telediagnosesystems besteht darin, dass es auf bereits vorhandenen, zentralen Diagnoseplattformen und bereits vorhandenen, im Fahrzeug angebrachten On- Board-Diagnosesystemen aufsetzt. Dadurch kann die Bedatung des Telediagnosesystems durch Nutzung bereits vorhandener Diagnoseprogramme und Diagnosesysteme erfolgen.
Durch Verwendung von Thesauren können die erzeugten Diagnoseergebnisse in verschiedenen Nationalsprachen angezeigt werden. Dies hat den Vorteil, dass der Techniker im Customer Assistance Center bei der Durchfuhrung der Diagnose seine Muttersprache wählen kann. Auch kann das Diagnoseergebnis in der Muttersprache des Fahrzeugfuhrers übersetzt und zur Anzeuge im Fahrzeug übertragen werden.
Nicht zuletzt bietet die Verwendung von XML-Datenstrukturen den Vorteil, dass Diagnoseergebnisse von den verwendeten Da- tenformaten der Off-Board-Systeme und der On-Board-Systeme, die oftmals mit nicht durchschaubaren Fehlercodes arbeiten, unabhängig werden. Mit dem XML-Datenformat lassen sich auch Web-basierte Anwendungen realisieren. So können über Internetverbindungen oder Intranetverbindungen die Diagnoseergebnisse, die im Customer Assistance Center angefallen sind, an jede ans Internet angeschlossene Werkstatt weitergeleitet werden und von dem Service-Techniker in der Werkstatt eingesehen werden. Der Diagnosespezialist im Customer Assistance Center und der Service-Techniker in der Werkstatt haben auf diese Weise stets den gleichen aktuellen Informationsstand vor Augen und können sich ggf. über eine Telefonleitung beraten.
Ausfuhrungsbeispiele der Erfindung werden im Folgenden anhand der Figuren naher erläutert. Es zeigen:
Fig. 1 ein Schichtenmodell für das Telediagnosesystem mit den zugehörigen Modulen;
Fig. 2 eine Prozessubersicht für das Telediagnosesystem;
Fig. 3 eine mögliche Serverstruktur für das Telediagnosesystem im Customer Assistance Center;
Fig. 4 die Anbmdung der Anwendungsmodule an das zentrale Diagnoseprogramm;
Fig. 5 ein Blockschaltbild eines Service Assistant Servers;
Fig. 6 eine Veranschaulichung des Variantenhandlings für verschiedene Baureihen;
Fig. 7 einen Bildschirmauszug des Telediagnose-Viewers im Customer Assistance Center.
Anhand von Figur 1 wird im Folgenden die Grundstruktur des erfindungsgemaßen Telediagnosesystems vorgestellt. Für die Pannenfallabwicklung in einem Call Center, einem sogenannten Customer Assistance Center, abgekürzt CAC, wird ein Telediagnosesystem in Form eines Datenverarbeitungssystems vorge- stellt, welches die Telediagnosedaten aus verschiedenen Baureihen verarbeiten und anzeigen kann. Im Customer Assistance Center ist auf einer zentralen Datenverarbeitungsplattform ein Diagnoseprogramm implementiert. Das Diagnoseprogramm verfugt über eine Verbindung zu einer zentralen Diagnose Datenbank, in der diagnoserelevante Informationen über Struktur der zu diagnostizierenden Fahrzeuge, Erfahrungswissen aus der Vergangenheit sowie Kennungen zur Identifikation der Fahrzeuge und der Steuergerate im Fahrzeug selbst abgelegt sind. Das Diagnoseprogramm hat eine Kommunikationsschnittstelle zu den Servern im Custom Assitant Center. Die Telediagnosedaten werden eingangsseitig über eine funkbasierte Kommunikationsschnittstelle 1 in das Diagnosesystem eingelesen. Die funkbasierte Kommunikationsschnittstelle beruht auf den an sich bekannten Standards für Mobilfunk, insbesondere auf den unter GSM und SMS bekannten Formaten der Datenübertragung (SMS für Short Message Service) . Um die Calls von eingehenden Mobilfunknachrichten aus verschiedenen Fahrzeugen aufnehmen zu können, verfugt das Telediagnosesystem über eine zentrale Kommunikationsplattform Telematic Services Kernel (TS- Kernel) und eine Kundendatenbank TSDB. Die Kommunikationsplattform fuhrt mit Hilfe der Kundendatenbank für die eingehenden Calls aus den Fahrzeugen eine Berechtigungsabfrage durch. Hierbei wird im wesentlichen überprüft, ob das anfragende Fahrzeug in der Kundendatenbank TSDB registriert ist. Zur Identifizierung des Fahrzeugs wird die Fahrzeugidentifikationsnummer FIN verwendet.
Weitere Aufgabe der zentralen Kommunikationsplattform ist es, mit Hilfe der durch den Mobilfunk übermittelten GPS Daten die aktuelle Position des Fahrzeugs zu bestimmen. Hierzu sind in der Kundendatenbank TSDB zusatzlich digitale Land- und Straßenkarten abgelegt, mit deren Hilfe die Kommunikationsplat- form TS-Kernel die Position des Fahrzeugs ermittelt und gege- benenfalls die zu dem Fahrzeug nächste Service-Station, in der das Fahrzeug repariert werden kann, ermittelt.
Der Umfang der zur Verfugung stehenden Diagnosedaten, die vom On-Board-System im Fahrzeug zum Telediagnosesystem im Customer Assistance Center übertragen werden können, umfasst hierbei insbesondere die folgenden Daten:
Statusinformationen über Zustandswerte des Fahrzeugs, wie z. B. Batteriespannung, Zundstellung, Positionsdaten, Kilometerstand, Tankfullung und die Fahrzeugidentifikation (FIN). Diese Daten werden in einer sogenannten Initial TD Message als initiales Datenpaket übermittelt.
Weitere Informationsblocke, welche erst nach Anforderung übermittelt werden, betreffen z.B. Basic Data, Power Management Data, Status Data, Maintenance Computer Data, Vehicle Configuration Data, Status of Services, Statusinformationen der Systemdiagnose, verdachtige Komponenten, I- dentifikationsblocke der Steuergerate, fehlerhafte Steuergerate, Steuergerate-Fehlercodes, betroffene Funktionen.
Im Gegensatz zu vorbekannten Telediagnosesystemen werden mit dem initialen Datenpaket „Initial TD Message" zunächst Grunddaten vom Fahrzeug zu dem Telediagnosesystem im Customer Assistance Center übertragen. In einem weiteren Schritt können die oben angeführten weiteren Informationsblocke aus dem On- Board-System des Kraftfahrzeugs nach Anforderung und nach Bedarf ausgelesen werden und vom Fahrzeug auf das Telediagnosesystem übertragen werden.
Bei der Anwendung des Telediagnosesystems auf Nutzfahrzeuge und Lastkraftwagen wird nicht die direkte Kommunikation zwischen Fahrzeug und Customer Assistance Center bevorzugt, son- dern es wird der Datenaustausch über einen zentral installierten Fleet-Board-Server, der vorzugsweise von den Transport- und Logistikunternehmen genutzt wird, versendet. Übertr gen werden hierbei Status und Identifizierung des Fahrzeugs, Positionsdaten, Telefonnummer und Sprache des Fahrers, Datum und Uhrzeit sowie Informationen zum Fahrzeugzustand inklusive des Steuergerate- Fehlercodes. Über den Fleet-Board Server besteht auch Zugang zu den aktuellen Wartungsdaten des Fahrzeugs .
Zur Kommunikationsanbindung im Customer Assistance Center hat die Kommunikationsplattform TS-Kernel zwei weitere Schnittstellen. Über ein Server-Interface SAS-Interface ist der TS- Kernel mit einem sogenannten Service Assistant Server SAS- Server im Rechnernetzwerk des Call Centers verbunden. Über eine mögliche zweite Schnittstelle CSR-Interface ist der TS- Kernel mit dem Rechnernetzwerk für die Bildschirmarbeitsplätze im Call Center im Customer Assistance Center Local Area Network CAC-LAN verbunden. Über die Bildschirmarbeitsplätze im Customer Assistance Center Local Area Network haben die Mitarbeiter im Call Center, die sogenannten Customer Service Representatives CSR, eine Emflussmoglichkeit über den Kommu- nikationsablauf im TS-Kernel. Insbesondere können sie über das CSR-Interface gezielt Daten nachfordern.
Mit dem Service Assistant Server SAS-Server werden die übertragenen Diagnosedaten aufbereitet und über eine Mensch- Maschme-Schnittstelle MMI in Form eines Telediagnose-Viewers den Mitarbeitern im Call Center zur Anzeige gebracht. Der Service Assistant Server im Call Center umfasst zur Datenaufbereitung hauptsächlich die folgenden Module:
Einen Datenkonverter, der mittels einer Konverterkonfiguration die verschiedenen Datenprotokolle, die in verschie- denen Board-Netzen von Personenkraftwagen und Lastkraftwagen im Einsatz sein können, in ein einheitliches Datenformat, insbesondere in eine XML-Struktur, konvertiert.
Einen Datenvervollstandiger, der mittels einer Vervoll- standiger-Konflguration baureihenspezifische Datennachforderungen per Anfrage „Request" an das SAS-Interface über das Diagnoseprogramm aus dem zu diagnostizierenden Fahrzeug ausliest. Die vervollständigten Daten werden auf dem Telediagnose-Viewer MMI zur Anzeige gebracht.
Die DV-gestutzten Systeme für den Service Assistant Server für das eigentliche Diagnoseprogramm sowie für die Arbeits- platzrechner im Local Area Network des Call Centers beruhen auf dem Betriebssystem Windows NT4. Als Datenverbindung zwischen den Systemen ist das TCP/IP-Protokoll Standard. Geeignete Alternativen kann auch ein Unix/Linux-basiertes System sein. Die Leistungsfähigkeit des Telediagnosesystems berücksichtigt hierbei die Echtzeitanforderungen des Diagnoseprozesses, um einen Kontakt zwischen dem Mitarbeiter im Call Center und einem Service-Techniker in der Werkstatt in Echtzeit zu ermöglichen. Hierzu gehört auch die Fähigkeit, mehrere Fahrzeuge gleichzeitig diagnostizieren zu können.
Figur 2 gibt eine Prozessubersicht über die auf dem Service Assistant Server SAS-Server ablaufenden Prozesse. Zentrales Element für die Kommunikation zwischen den verschiedenen Prozessen ist hierbei eine Fehlerfallkennung Telematic Services Identifier (TSID) , die von der zentralen Kommunikationsplattform TS-Kernel einem eingehenden Call aus einem Kraftfahrzeug zugeordnet wird. Mittels der Fehlerfallkennung werden die verschiedenen Teilprozesse synchronisiert und die Ergebnisse der verschiedenen Teilprozesse eindeutig einem anliegenden aktuellen Diagnoseprozess zugeordnet. Zunächst wird das vom Fahrzeug eingehende initiale Datenpaket im TS-Kernel einer Berechtigungsuberprufung unterzogen. Nach positiver Berechtigungsuberprufung wird die Schnittstelle zum SAS-Server initialisiert und im SAS-Server wird das erste initiale Datenpaket analysiert und anhand einer Logik wird eine automatische Da- tenvervollstandigung durchgeführt .
Dieses aufbereitete erste Diagnoseergebnis wird mit einem Thesaurus in Textform aufbereitet und auf einem Telediagnose- Viewer zur Anzeige gebracht. Der Telediagnose-Viewer dient hierbei der Visualisierung des Diagnoseergebnisses und auch der weiteren Steuerung, falls noch ein weiterer Diagnoseablauf erforderlich ist. Die automatische Datenvervollstandi- gung erfolgt mittels einer Vervollstandiger-Konfiguration, die im Wesentlichen eine Umsetzungstabelle ist, in der festgehalten ist, welche baureihenspezifischen Daten zusatzlich in den Diagnoseprozess unter Berücksichtigung des aktuellen Fahrzeugzustandes eingebunden werden sollen, d.h. welche wie- lteren dynamischen Daten (z.B. Fehlercodes der Steuergerate) , die Rückschlüsse auf den vorliegenden Fehler geben können, angefordert werden sollen. Die baureihenspezifischen Daten sind mit der Datenbereitstellung symbolisiert. Anhand des vi- sualisierten Diagnoseergebnisses und der Fehlerfallkennung TSID können die Mitarbeiter im Call Center (CSR für Customer Service Representative) weitere Informationen einholen und den weiteren Ablauf des Diagnoseprozesses gezielt steuern. Der eingehende Call wird bei dem ganzen Diagnoseprozess zusammen mit der Fehlerfallkennung TSID über einen automatischen Verteiler (Dispatcher) zusammen mit der Fehlerfallkennung einem Mitarbeiter (CSR für Customer Service Representative) im Call Center zur Bearbeitung zugewiesen. Mittels der Fehlerfallkennung TSID kann die Zuweisung der eingehenden Calls auf die Mitarbeiter im Call Center entsprechend der Qualifikationen der Mitarbeiter spezifisch erfolgen. So kann z. B. ein Fehler im Motorsteuergerat gezielt an einen Spezialisten für Motorsteuergerate geleitet werden oder ein Fehler im Antiblockiersystem kann gezielt an einen Spezialisten für Antiblockiersysteme weitergeleitet werden.
Figur 3 verdeutlicht die Minimalanforderungen an die Netzwerkstruktur im Call Center. Über ein Customer Assistance Center Local Area Network CAC-LAN sind mehrere DV-Plattformen CSR-Workstation als SAS-Clients an den SAS-Server und an den TS-Server angeschlossen. Der SAS-Server ist dabei der bereits erwähnte Service Assistant Server, wahrend der TS-Server die DV-Plattform für das Diagnoseprogramm darstellt. Der TS- Server und der SAS-Server kommunizieren hierbei über das SAS- Interface bzw. über das TS-Kernel-Interface sowie mit den SAS-Clients. Die Anbindung der SAS-Clients über ein Local A- rea Network bietet die Möglichkeit, von verschiedenen Arbeitsplatzrechnern aus, auf die Ergebnisse der Telediagnose, die von TS-Server und SAS-Server erstellt werden, zuzugreifen und auf den Arbeitsplatzrechnern mittels eines Telediagnose- Viewers zur Anzeige zu bringen.
Figur 4 verdeutlicht nochmals die Einbindung des Service Assistant Servers SAS in das Telediagnosesystem. Die Initiierung des Telediagnoseprozesses erfolgt fahrzeugseitig entweder ausgelost durch den Fahrer des Fahrzeugs oder durch selbsttätige Auslosung durch das fahrzeugseitige On-Board- Diagnosesystem. Die Auslosung des Telediagnoseprozesses durch den Fahrer erfolgt hierbei z.B. durch Betätigung einer speziellen Taste im Fahrzeug, mit der der Telediagnoseprozess ausgelost werden kann. Bei selbsttätiger Auslosung des Tele- diagnoseprozesse durch das fahrzeugseitige On-Board- Diagnosesystem wird der Telediagnoseprozess durch das Auftreten und Feststellen eines Fehlers im Fahrzeug selbst getrig- gert. Durch die Initiierung des Telediagnoseprozesses werden die On-Board-seitigen Daten m den Steuergeraten des Fahrzeugs bzw. im Fehlerspeicher des On-Board-Diagnosesystems aktualisiert und eine Datenverbindung zum TS-Kernel aufgebaut. Ein initiales Datenpaket, bestehend aus einer Fahrzeugidenti- fikation FIN, einem digitalen Zeitstempel und einer digitalen Fehlerinformation, wird über die Kommunikationsschnittstelle an den TS-Kernel gesandt. Der TS-Kernel überprüft anhand der Rohdaten aus dem Fahrzeug und den Eintragen in der Kundendatenbank Telematic Services Data Base (TSDB) die Zugriffsberechtigung auf das Telediagnosesystem und speichert das initiale Datenpaket in Form eines Datenobjektes ab. Dieses Datenobjekt erhalt als Kennung eine Fehlerfallkennung TSID. Der vom Fahrzeug eingehende Call lost im TS-Kernel einen Triggermechanismus für das Telediagnosesystem aus. Nach eingegangenem Call werden die Schnittstellen vom TS-Kernel zum Customer Assistance Center Local Area Network CAC-LAN und zum Service Assistant Server SAS initialisiert und aktiviert. Weiterhin wird der eingegangene Call über einen Verteiler (Dispatcher) einem Mitarbeiter CSR im Call Center zugewiesen. Die Steuerung des Datenflusses erfolgt hierbei über die Fehlerfallkennung TSID.
Anhand von Figur 5 wird im Folgenden naher auf die Arbeitsweise der Datenvervollstandigung eingegangen. Ein vom Kraftfahrzeug eingehender Call lost in der zentralen Kommunikationsplattform TS-Kernel einen Triggermechanismus für den Service Assistant Server SAS aus. Gleichzeitig wird das initiale Datenpaket aus dem On-Board-Diagnosesystem des Kraftfahrzeugs vom TS-Kernel an den Service Assistant Server SAS übergeben. Diese Daten und alle weiteren, auszutauschenden Telediagnosedaten werden, gesteuert durch die Konfiguration des Datenkonverters, in eine allen Baureihen des Kraftfahrzeugs gemeinsame XML-Datenstruktur konvertiert. Danach werden die konvertierten Daten durch eine softwaremaßig implementierte Logik in dem Programmmodul Datenvervollstandiger interpretiert. Dabei werden aufgrund der übermittelten Fehlerzustande diejenigen Datenblocke ermittelt, welche zusatzliche Informationen zu Fehlerzustanden liefern können. Dies sind z. B. Servicedaten, Betriebswerte, Status der On-Board-Systemdiagnose im Kraftfahrzeug, Steuergerate Fehlercodes, usw. Diese ermittelten Datenpakete, die aus dem Fahrzeug abgerufen werden können und zusatzliche Informationen zu den Fehlerzustanden liefern, werden vom Datenvervollstandiger automatisch per Request an den TS-Kernel übermittelt und von dem TS-Kernel aus dem Fahrzeug über die Kommunikationsschnittstelle angefordert und ausgelesen. Es wird beispielsweise der Status der On-Board- Systemdiagnose im Kraftfahrzeug angefordert, empfangen, konvertiert und interpretiert. Für jedes fehlerhafte Steuergerat im Kraftfahrzeug werden per Request die Diagnosedaten, z.B. die Fehlercodes zu dem betreffenden Steuergerat angefordert und übertragen. Die eintreffenden Daten werden wiederum durch das Modul Datenkonverter in eine für alle Baureihen gleiche XML-Struktur konvertiert und gespeichert. In der konvertierten Form der Telediagnosedaten sind die Bits und Bytes der Rohdaten durch die passenden Thesaurus-Indices ersetzt, welche die textuelle Beschreibung der Information repräsentieren. Zur Anzeige der Daten und der Diagnoseergebnisse auf dem Telediagnose-Viewer werden über die Thesaurus-Indices, welche bereits den ermittelten Fehlercodes zugewiesen wurden, die Thesaurus-Texte zur Anzeige gebracht. Die Thesaurus-Texte sind allgemein verstandliche Fehlertexte und enthalten insbesondere die Namen der diagnostizierten Bauteile. Der Mitarbeiter im Call Center kann die Sprache, in denen die Texte zur Anzeige gebracht werden sollen, durch Auswahl eines geeigneten Thesaurus wählen. Damit kann der Mitarbeiter im Call Center sich die Diagnoseergebnisse z. B. standardmäßig in Englisch anzeigen lassen oder aber für die Anzeige der Diagnoseergebnisse seine Muttersprache wählen. Der Datenkonverter hat die Aufgabe aus Rohdaten eine fahr- zeugunabhangige XML-Datenstruktur zu erzeugen. Die Konvertierungsvorschrift für jede Baureihe eines Kraftfahrzeugs wird aus einer baureihenspezifischen Konverterkonfiguration gewonnen. Der Dateiname für das konvertierte Diagnoseergebnis wird automatisch generiert und setzt sich aus der Fehlerfallkennung TSID und einem digitalen Zeitstempel zusammen. Für die Fehlerfallkennung TSID werden zum Beispiel zehn feste Stellen im Dateinamen reserviert. Nach der Fehlerfallkennung kommt der Zeitstempel, der Angaben über Jahr, Monat, Tag sowie Stunden, Minuten und Sekunden enthalt.
Der Datenvervollstandiger verarbeitet die vom Datenkonverter erzeugte XML-Datenstruktur weiter. Hierzu besitzt der Datenvervollstandiger eine über die Vervollstandiger-Konfiguration pro Baureihe eingestellte Logik. Die Telediagnosedaten in der XML-Datenstruktur werden mit dieser Logik ausgewertet. Notwendige Datennachforderungen an das Fahrzeug werden aufgrund der vorliegenden Daten und der Konfiguration bestimmt. Entsprechend der Auswahl, ob alle Daten oder nur fehlerrelevanten Daten geholt bzw. angezeigt werden sollen, werden nach dem Auswerten des ersten übermittelten, initialen Datenpakets die Requests für die Datennachforderung an das Fahrzeug formuliert und über den TS-Kernel abgesetzt. Das initiale Datenpaket enthalt Fahrzeugbasisdaten, wie z. B. eine Fahrzeugidentifikationsnummer FIN, den Zeitstempel, Positionsdaten des Fahrzeugs, Spannungswerte von Steuergeraten, die Zund- stellung des Zündschlüssels sowie Statusmeldungen ausgewählter Aggregate und den Status der Warnlampen im Fahrzeugdisplay. Weiterhin wird mit dem initialen Datenpaket eine Liste übertragen, in der von der On-Board-Diagnose als fehlerhaft gekennzeichnete Steuergerate markiert sind. Der Datenvervollstandiger analysiert die Daten aus dem initialen Datenpa- ket, das vom Datenkonverter in eine XML-Datei umgewandelt wurde. Die im initialen Datenpaket als fehlerhaft markierten Steuergerate fuhren nach Analyse durch den Datenvervollstandiger zu einer Datennachforderung, bei der aus dem fehlerhaft markierten Steuergerat weitere Daten, z. B. der Statusblock des Steuergeräts und die Fehlercodes, ausgelesen werden können. Sofern das dem Telediagnosesystem zugrunde liegende Diagnoseprogramm ein modellbasiertes Diagnoseprogramm ist, werden auch weitere Umgebungsdaten aus dem Kraftfahrzeug ausgelesen, die den aufgetretenen Fehler genauer beschreiben können. Diese Umgebungsdaten sind z. B. die Statusdaten der in der Hierarchie benachbarten Steuergerate des als Defekt diagnostizierten Steuergeräts. Alternativ können auch alle Fahrzeugdaten angefordert werden. Die Übermittlung der Datennachforderung erfolgt ebenfalls über die funkbasierte Kommunika- tionsschnittstelle, also über Mobilfunk und hierbei vorzugsweise über den SMS-Standard.
Die Auswertelogik für die Datennachforderung ist hierbei konfigurierbar gestaltet. Dies erlaubt die Anpassung der übermittelten Datenpakete an baureihenspezifische Besonderheiten der Kraftfahrzeuge. Die Konfiguration wird in einer XML-Datei festgehalten und ist in Figur 5 als Vervollstandiger-Konfl- guration bezeichnet. Die Informationen der Vervollstandiger- Konfiguration werden bei jedem neuen Call neu eingelesen und damit festgelegt, mit welcher weiteren Datennachforderung das Telediagnosesystem auf das zuvor eingegangene initiale Datenpaket reagiert. Die Vervollstandiger-Konfiguration ist baureihenspezifisch und kann bei Änderungen in der Baureihe der Kraftfahrzeuge entsprechend angepasst werden. Kommt das Diagnoseprogramm mit den nachgeforderten Daten zu keinem befriedigenden Diagnoseergebnis, so gibt es zusätzlich zu der bereits beschriebenen, automatisch getriggerten Datennachforderung auch die Möglichkeit der Datennachforderung durch den Mitarbeiter im Call Center. Hierzu wird das bisherige Diagnoseergebnis auf dem Telediagnose-Viewer zur Anzeige gebracht. Der Mitarbeiter im Call Center kann nun das bisherige Diagnoseergebnis beurteilen. Zur weiteren manuellen Datennachforderung kann der Mitarbeiter im Diagnosecenter über das Diagnoseprogramm gezielt weitere Statusdaten des Kraftfahrzeugs anfordern und auslesen lassen. Der Mitarbeiter im Call Center hat auch die Möglichkeit, über eine Telefonverbindung den Fahrer des Kraftfahrzeugs zu den auftretenden Fehlersymptomen im Kraftfahrzeug zu befragen.
Anhand von Figur 6 wird im Folgenden nochmals naher auf die Visualisierung des Diagnoseergebnisses auf dem Telediagnose- Viewer eingegangen. Für die Visualisierung des Telediagnose- ergebnisses müssen die Daten zunächst über einen Prozess „Einbindung des Thesaurus" mit den entsprechenden Thesaurus- Texten verknüpft werden. Die Einbindung des Thesaurus übernimmt ein Linker. Dazu sind Tabellen zur Interpretation der vom Fahrzeug gesendeten Daten (Fehlercodes und andere Informationen) vorhanden. Dazu gehören auch Steuertabellen für die Identifizierung der im Fahrzeug verbauten Steuergerate Varianten. Die eingebauten Steuergeratevarianten variieren in der Regel von einer Baureihe zur nächsten. Die Identifikation der verbauten Steuergerate erfolgt durch das On-Board-seitige Diagnosesystem, beispielsweise mittels der Netzwerkadressen o- der weiterer Steuergeratedaten der Steuergerate. Diese Netzwerkadressen sind vorzugsweise sogenannte CAN-Identifier . Aus den aus der Stammdatenversorgung (SGS-Datei) ermittelten Angaben zur Steuergeratestruktur, zu den Steuergeratevarianten und den für die verbauten Steuergerate möglichen Fehlercodes wird mittels eines Textgenerators eine baureihen- und fahrzeugspezifische Textliste erzeugt, die in Form einer Datei die für dieses Fahrzeug relevanten Thesaurus-Indices enthalt. Über die Thesaurus-Indices kann spater der Linker die rele- vanten zugeordneten Thesaurus-Texte in den verschiedenen Sprachen, die im Telediagnosesystem zur Anzeige ausgewählt werden können, verbinden. Die Auswahl, welche Texte letztendlich zur Ausgabe gebracht werden sollen, hangt von dem jeweils vorliegenden Diagnosedaten ab. Hierzu werden die vom Fahrzeug eingehenden SMS-Datenpakete analysiert und, wie im Zusammenhang mit Figur 5 erläutert, ein aufbereitetes und strukturiertes Diagnoseergebnis in Form von Telediagnosedaten erzeugt. Über den Fehlercode des Diagnoseergebnisses und über die Thesaurus-Indices, die auf diese Fehlercodes referenzie- ren, wird der für dieses Diagnoseergebnis relevante Fehlertext ausgewählt und dem Diagnoseergebnis hinzugebunden. Dies dermaßen erzeugte, strukturierte Diagnoseergebnis wird entweder zur Anzeige gebracht oder als Fahrzeugausgabedatei auf einem Speichermedium des Service Assistant Servers zwischengespeichert .
Figur 7 zeigt schließlich eine Visualisierung des mit dem vorbeschriebenen Telediagnosesystem und dem vorbeschriebenen Telediagnoseverfahren erzeugten Diagnoseergebnisses auf dem Telediagnose-Viewer. Man erkennt die Fehlerfallkennung TSID, den digitalen Zeitstempel sowie Fahrzeuggrunddaten, wie Fahrzeugidentifikationsnummer FIN und den Kilometerstand des Fahrzeugs. Der Fahrzeugzustand gibt Auskunft über die aufgetretenen Fehler. In dem gezeigten Ausfuhrungsbeispiel wurde festgestellt, dass das Fernlicht auf der Fahrerseite defekt ist und der Motorolstand ein Minimum erreicht hat. Weiterhin wurde ein Defekt im elektronischen Stabilitatsprogramm ESP festgestellt, was im Kombiinstrument durch eine blinkende ESP-Infolampe angezeigt wurde. Als Ursache für die blinkende ESP-Infolampe wurden von dem Telediagnosesystem zwei mögliche Fehlerursachen ermittelt. Die Fehlerursachen werden mit dem Fehlercode und dem diesem Fehlercode zugeordneten Thesaurus- Text zur Anzeige gebracht. Wahrend die Defekte des Fernlichts sowie das ungenügend arbeitende elektronische Stabilitatspro- gra m als Fehler von dem Fahrzeugfuhrer wahrgenommen werden können, können die Fehler betreffend des Sicherheitssystems Airbag, die ebenfalls festgestellt wurden, vom Fahrzeugfuhrer nicht ohne weiteres wahrgenommen werden. Bei den Airbags wurden zwei Fehler festgestellt. Zum einen hat die Leitung zum Gurtschloss vorne links einen Kurzschluss und zum anderen wurde mindestens ein Airbag im Fond des Fahrzeugs nicht korrekt kodiert, d.h. die Programmierung der angeschlossenen Peripherie im Steuergerat Airbag muss überprüft werden.

Claims

Patentansprüche
1. Diagnosesystem für Kraftfahrzeuge bestehend aus:
- mindestens einer Off-Board-Diagnoseplattform mit einem Diagnoseprogramm und mit einer zugehörigen Wissensbasis, in der Strukturdaten über die zu diagnostizierenden Systeme sowie eine Wissensbasis über die systemspezifischen Fehlermeldungen und deren möglichen Fehlerursachen enthalten sind,
mit mindestens einer funkbasierten Kommunikationsschnittstelle (1) zum Aufbau einer Datenverbindung der Diagnoseplattform mit einer fahrzeugseitigen Kommunikationsschnittstelle, die mit fahrzeugseitigen Steuergeräten verbunden ist,
- wobei im Fahrzeug aus Steuergeräten Statusinformationen ausgelesen werden und daraus ein initiales Datenpaket gebildet wird, das mit dem Diagnoseprogramm ausgelesen und daraus ein erstes Diagnoseergebnis berechnet wird,
- mit mindestens einer Anwenderschnittstelle (CSR-Inter- face, SAS-Interface) der Diagnoseplattform zu einem Anwender-Rechner-Netzwerk (CAC-LAN) mit mindestens einem Bildschirm-Arbeitsplatz auf dem ein Telediagnose-Viewer
(MMI) installiert ist,
d a d u r c h g e k e n n z e i c h n e t , dass der Telediagnose-Viewer die Bedien-Schnittstelle zu einem Server (SAS-Server) ist, und der Server das Diagnoseergebnis bedarfsgesteuert erweitert, indem er das Diagnoseergebnis mit weiteren Daten vervollständigt.
2. Diagnosesystem nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, dass der Server (SAS-Server) einen Datenkonverter enthalt, der mittels einer Konverter-Konfiguration das initiale Datenpaket in eine XML-Struktur umwandelt und als XML-Datei abspeichert.
3. Diagnosesystem nach Anspruch 1 oder 2, d a d u r c h g e k e n n z e i c h n e t, dass der Server (SAS-Server) einen Datenvervollstandiger enthalt, der mittels einer baureihenspezif schen Logik das initiale Datenpaket analysiert und bei Bedarf mittels weiteren baureihenspezifischen Anfragen (Requests) über das Diagnoseprogramm und die Kommunikationsschnittstelle weitere Diagnoseinformationen ausliest und diagnostiziert .
4. Diagnosesystem nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass der Server (SAS-Server) mindestens einen Thesaurus enthalt .
5. Diagnosesystem nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, das ein Flottenserver oder ein anderes Gateway zu den Fahrzeugdaten enthalten ist.
6. Diagnosesystem nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass das initiale Datenpaket eine digitale Fahrzeugidentifikation (FIN), Statusinformationen, eine Fehleruber- sieht , die Fahrzeugposition oder einen digitalen Zeitstempel enthalt.
7. Diagnoseverfahren für Kraftfahrzeuge basierend auf:
- mindestens einer Off-Board-Diagnoseplattform mit einem Diagnoseprogramm und mit einer zugehörigen Wissensbasis, in der Strukturdaten über die zu diagnostizierenden Systeme sowie eine Wissensbasis über die systemspezifischen Fehlermeldungen und deren möglichen Fehlerursachen enthalten sind,
mit mindestens einer funkbasierten Kommunikationsschnittstelle (1) zum Aufbau einer Datenverbindung der Diagnoseplattform mit einer fahrzeugseitigen Kommunikati- onsschnittstelle, die mit fahrzeugseitigen Steuergeraten verbunden ist,
- wobei im Fahrzeug aus Steuergeraten Statusinformationen ausgelesen werden und daraus ein initiales Datenpaket gebildet wird, das mit dem Diagnoseprogramm ausgelesen und daraus ein erstes Diagnoseergebnis berechnet wird,
- mit mindestens einer Anwenderschnittstelle (CSR-Inter- face, SAS-Interface) der Diagnoseplattform zu einem Anwender-Rechner-Netzwerk (CAC-LAN) mit mindestens einem Bildschirm-Arbeitsplatz auf dem ein Telediagnose-Viewer (MMI) installiert ist, wobei der Telediagnose-Viewer die Bedien-Schnittstelle für das Diagnoseverfahren ist,
d a d u r c h g e k e n n z e i c h n e t ,
- dass in einem ersten Schritt bei Auftreten einer Störung eine erste Kurzmitteilung (SMS), enthaltend eine Fahrzeugidentifikationsnummer und mindestens eine Fehlerfallkennung (TSID) , an die Diagnoseplattform gesendet wird und ein erstes Diagnoseergebnis in Form eines miti- alen Datenpaketes berechnet wird,
- und dass in einem zweiten Schritt bedarfsgesteuert weitere Statusinformationen aus fahrzeugseitigen Steuergeraten ausgelesen werden und damit das Diagnoseergebnis vervollständigt wird.
8. Diagnoseverfahren nach Anspruch 7, d a d u r c h g e k e n n z e i c h n e t, dass das initiale Datenpaket mittels eines Datenkonverters und einer Konverter-Konfiguration in eine XML-Struktur umgewandelt wird und als XML-Datei abgespeichert wird.
9. Diagnoseverfahren nach Anspruch 7 oder 8, d a d u r c h g e k e n n z e i c h n e t, dass das initiale Datenpaket mittels eines Datenvervoll- standigers, der eine baureihenspezifische Logik enthalt, analysiert wird und mittels baureihenspezifischer weiterer Anfragen (Requests) das Diagnoseergebnis ergänzt wird.
10. Diagnoseverfahren nach Anspruch 8 oder 9, d a d u r c h g e k e n n z e i c h n e t, dass die Elemente der XML-Datei über Indices mit mindestens einem Thesaurus verbunden sind und auf dem Telediagnose-Viewer (MMI) die Textbausteine aus dem Thesaurus angezeigt werden.
11. Diagnoseverfahren nach Anspruch 10, d a d u r c h g e k e n n z e i c h n e t, dass mehrere auswahlbare Thesauren in verschiedenen Sprachen vorhanden sind.
12. Diagnoseverfahren nach einem der Ansprüche 7 bis 11, d a d u r c h g e k e n n z e i c h n e t, dass das initiale Datenpaket eine digitale Fahrzeugiden- tifikation (FIN), Statusinformationen, eine Fehleruber- sicht , die Fahrzeugposition oder einen digitalen Zeitstempel enthalt.
13 . Diagnoseverfahren nach einem der Ansprüche 1 bis 11 , d a d u r c h g e k e n n z e i c h n e t , dass die Datenverbindung von der Diagnoseplattform zum Fahrzeug über einen Fleet-Board-Server geht.
14. Mensch-Maschme-Schnittstelle (MMI) für ein Diagnosesystem zur Diagnose eines technischen Systems mit einer Wissensbasis und einem Diagnoseprogramm, das ein erstes Diagnoseergebnis in Form eines initialen Datenpaketes bereitstellt, umfassend:
- einen Datenkonverter, der anhand einer Konverter-Konfiguration das initiale Datenpaket in eine XML-Struktur umwandelt und als XML-Datei abspeichert,
- einen Datenvervollstandiger, der die Daten der XML-Datei analysiert und anhand der Daten des initialen Datenpaketes (TSID) oder nach Setzen einer manuellen Anforderung (Request) weitere Daten aus dem zu diagnostizierenden technischen System ausliest und nach Konvertierung mittels einer Vervollstandiger-Konfiguration der XML-Datei hinzuspeichert,
- und eine Visualisierung der in der XML-Datei abgespeicherten XML-Elemente in Form einer interaktiven Benutzeroberflache.
PCT/EP2004/004043 2003-05-23 2004-04-16 Diagnosesystem WO2004104604A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/558,081 US20070100519A1 (en) 2003-05-23 2004-04-16 Diagnostic system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10323384A DE10323384A1 (de) 2003-05-23 2003-05-23 Diagnosesystem
DE10323384.9 2003-05-23

Publications (1)

Publication Number Publication Date
WO2004104604A1 true WO2004104604A1 (de) 2004-12-02

Family

ID=33441219

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/004043 WO2004104604A1 (de) 2003-05-23 2004-04-16 Diagnosesystem

Country Status (3)

Country Link
US (1) US20070100519A1 (de)
DE (1) DE10323384A1 (de)
WO (1) WO2004104604A1 (de)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1583039A1 (de) * 2004-03-30 2005-10-05 Scania CV AB Fahrzeug und Verfahren für ein Fahrzeug
WO2006040560A1 (en) * 2004-10-15 2006-04-20 Black Spot Interactive Ltd Apparatus and method for monitoring the usage status of an asset
WO2006071457A1 (en) * 2004-12-29 2006-07-06 Snap-On Incorporated Device and method for producing computer readable formatted output
DE102005011748A1 (de) * 2005-03-11 2006-09-14 Volkswagen Ag Verfahren und Anordnung zum Diagnostizieren von eingebetteten Systemen
WO2006128788A1 (de) * 2005-06-03 2006-12-07 Robert Bosch Gmbh Verfahren zur modellbasierten diagnose eines mechatronischen systems
WO2007098781A1 (de) * 2006-02-28 2007-09-07 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur drahtlosen fehlerbeseitigung an einem kraftfahrzeug
EP2278424A1 (de) * 2009-07-21 2011-01-26 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Diagnosesystems für ein Kraftfahrzeug und Diagnosesystem zur Ausführung des Verfahrens
CN102023621A (zh) * 2010-08-20 2011-04-20 上海自动化仪表股份有限公司 车载接口设备及其数据采集处理方法
CN102981496A (zh) * 2012-11-14 2013-03-20 深圳市元征科技股份有限公司 基于车辆专业诊断的远程监控及数据存储方法
WO2014202269A1 (de) * 2013-06-19 2014-12-24 Robert Bosch Gmbh Modul und system zur fahrzeugdiagnose
CN106289794A (zh) * 2015-05-25 2017-01-04 上海汽车集团股份有限公司 整车测试的数据处理方法和装置
FR3081594A1 (fr) * 2018-05-23 2019-11-29 Psa Automobiles Sa Procede de diagnostic d’un vehicule automobile a distance avec communication internet.
CN113325831A (zh) * 2021-06-24 2021-08-31 江铃汽车股份有限公司 一种平台化的汽车刷写诊断的网关路由方法

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004052780B4 (de) * 2004-10-30 2007-10-31 Audi Ag Fahrzeugservicesystem sowie Verfahren zur Durchführung einer Fahrzeugdiagnose
DE102005015664A1 (de) * 2005-04-06 2006-10-12 Daimlerchrysler Ag Diagnosesystem zur Bestimmung einer gewichteten Liste möglicherweise fehlerhafter Komponenten aus Fahrzeugdaten und Kundenangaben
DE102005044236B4 (de) * 2005-09-16 2019-02-28 Volkswagen Ag Diagnosegerät
DE102006009098A1 (de) * 2006-02-28 2007-08-30 Daimlerchrysler Ag Kraftfahrzeugdiagnose und Fahrzeugannahme
DE102006017644B4 (de) * 2006-04-12 2008-04-17 Dr.Ing.H.C. F. Porsche Ag Erfassung und Diagnose von Fahrzeugdaten
DE102006018831A1 (de) * 2006-04-22 2007-10-25 Daimlerchrysler Ag Kraftfahrzeugdiagnose und Fahrzeugannahme
DE102006042099A1 (de) * 2006-09-07 2008-03-27 Siemens Ag Diagnosesystem mit Exportmitteln und Verfahren zur Diagnose eines abgeschlossenen technischen Systems
US7693648B2 (en) * 2007-11-27 2010-04-06 Caterpillar Inc. System and method for detecting misassembly of an exhaust aftertreatment system of a machine
US8489289B2 (en) * 2008-02-19 2013-07-16 Conti Temic Microelectronic Gmbh Converter for signals between a safety device and a safety control device for a vehicle
DE102008010628A1 (de) 2008-02-22 2009-08-27 Daimler Ag Verfahren zum Erfassen von Diagnosedaten in einem Kraftfahrzeug mittels eines flüchtigen Ringspeichers und anschließender Datenreduktion in einen nichtflüchtigen Speicher
CN101520883A (zh) * 2008-02-29 2009-09-02 鸿富锦精密工业（深圳）有限公司 车辆维修系统及方法
US8315759B2 (en) * 2008-04-04 2012-11-20 GM Global Technology Operations LLC Humidity sensor diagnostic systems and methods
US7936261B2 (en) * 2008-09-26 2011-05-03 Caterpillar Inc. System and method for testing a machine using an interactive test script
US8229462B2 (en) 2008-12-03 2012-07-24 Htiip, L.L.C. Method and system for providing assistance resource progress information along a route
US8447465B2 (en) * 2010-02-24 2013-05-21 Denso International America, Inc. Method of activating a telematics device
US10600096B2 (en) 2010-11-30 2020-03-24 Zonar Systems, Inc. System and method for obtaining competitive pricing for vehicle services
US10665040B2 (en) 2010-08-27 2020-05-26 Zonar Systems, Inc. Method and apparatus for remote vehicle diagnosis
WO2012040182A2 (en) * 2010-09-20 2012-03-29 Agco Corporation Billing management system for agricultural services access
DE102010051040A1 (de) 2010-11-11 2011-06-16 Daimler Ag Verfahren zur Fehlerdiagnose bei einem Kraftfahrzeug und Diagnosesystem für ein Kraftfahrzeug
SE1051246A1 (sv) * 2010-11-29 2012-05-30 Scania Cv Ab Fjärrdiagnostisering av fordon
US10482475B2 (en) 2011-02-10 2019-11-19 Adp Dealer Services, Inc. Systems and methods for providing targeted advertising
DE102011076638A1 (de) * 2011-05-27 2012-11-29 Stephan Kaufmann Verfahren zur Fahrzeugkommunikation über ein fahrzeugimplementiertes Fahrzeugdiagnosesystem, Schnittstellenmodul sowie Fahrzeugdiagnose-Schnittstelle und Diagnose- und Steuerungsnetz für eine Vielzahl von Fahrzeugen
US9157390B2 (en) 2011-09-21 2015-10-13 GM Global Technology Operations LLC Selective exhaust gas recirculation diagnostic systems and methods
US9249764B2 (en) 2012-03-06 2016-02-02 GM Global Technology Operations LLC Engine control systems and methods with humidity sensors
US10066564B2 (en) 2012-06-07 2018-09-04 GM Global Technology Operations LLC Humidity determination and compensation systems and methods using an intake oxygen sensor
US8738664B2 (en) * 2012-05-23 2014-05-27 Lg Chem, Ltd. System and method for generating diagnostic test files associated with a battery pack
US9761063B2 (en) 2013-01-08 2017-09-12 Lytx, Inc. Server determined bandwidth saving in transmission of events
US9341133B2 (en) 2013-03-06 2016-05-17 GM Global Technology Operations LLC Exhaust gas recirculation control systems and methods
US11080734B2 (en) 2013-03-15 2021-08-03 Cdk Global, Llc Pricing system for identifying prices for vehicles offered by vehicle dealerships and other entities
US9037572B2 (en) 2013-06-03 2015-05-19 Honda Motor Co., Ltd. Event driven snapshots
US9165413B2 (en) 2013-06-03 2015-10-20 Honda Motor Co., Ltd. Diagnostic assistance
US9524592B2 (en) 2013-06-03 2016-12-20 Honda Motor Co., Ltd. Driving analytics
US9228524B2 (en) 2013-08-15 2016-01-05 GM Global Technology Operations LLC Static and dynamic pressure compensation for intake oxygen sensing
DE102013220922A1 (de) * 2013-10-16 2015-04-16 Zf Friedrichshafen Ag Telematiksystem, Verfahren und Telematikfahrzeugeinheit
FR3013458B1 (fr) 2013-11-21 2015-12-04 Peugeot Citroen Automobiles Sa Interface de communication virtuelle pour diagnostic de vehicule automobile
US9286736B2 (en) * 2013-12-16 2016-03-15 Manish Punjabi Methods and systems of vehicle telematics enabled customer experience
US20160225198A1 (en) * 2013-12-16 2016-08-04 Manish Punjabi Methods and systems of vehicle telematics enabled customer experience
DE102014214425A1 (de) * 2014-07-23 2016-01-28 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Fehleranalyse eines Produktes und Analysesystem
FR3028068B1 (fr) * 2014-10-30 2016-12-02 Peugeot Citroen Automobiles Sa Procede, equipement et systeme d’aide au diagnostic
DE102015223277A1 (de) * 2015-11-25 2017-06-01 Robert Bosch Gmbh Verfahren und Vorrichtung zum Verwalten eines Fahrzeuges
DE102015121178A1 (de) * 2015-12-04 2017-06-08 Endress + Hauser Gmbh + Co. Kg Verfahren zum Abspeichern von Messdatenpaketen in einem Feldgerät
GB2546253B (en) 2016-01-06 2020-04-22 Ge Aviat Systems Ltd Fusion of aviation-related data for comprehensive aircraft system health monitoring
US10867285B2 (en) 2016-04-21 2020-12-15 Cdk Global, Llc Automatic automobile repair service scheduling based on diagnostic trouble codes and service center attributes
US10853769B2 (en) * 2016-04-21 2020-12-01 Cdk Global Llc Scheduling an automobile service appointment in a dealer service bay based on diagnostic trouble codes and service bay attributes
US9652748B1 (en) * 2016-06-13 2017-05-16 State Farm Mutual Automobile Insurance Company Technology for automatically identifying and scheduling provider appointments in response to accident events
US10399706B1 (en) * 2016-06-22 2019-09-03 Amazon Technologies, Inc. Unmanned aerial vehicle maintenance troubleshooting decision tree
DE102016009199B4 (de) 2016-07-27 2023-09-28 Audi Ag Verfahren zum Betreiben einer Datenerfassungseinheit zum Erfassen von mindestens einem Steuerungsereignis einer Steuerungvorrichtung eines Kraftfahrzeugs sowie eine Datenerfassungseinheit und eine Datenverarbeitungseinheit
DE102016222473A1 (de) * 2016-11-16 2018-05-17 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Überprüfen eines Kraftfahrzeugs, insbesondere eines Kraftwagens, sowie Diagnosegerät zum Durchführen eines solchen Verfahrens
US11501351B2 (en) 2018-03-21 2022-11-15 Cdk Global, Llc Servers, systems, and methods for single sign-on of an automotive commerce exchange
US11190608B2 (en) 2018-03-21 2021-11-30 Cdk Global Llc Systems and methods for an automotive commerce exchange
DE102019201207A1 (de) 2019-01-30 2020-07-30 Volkswagen Aktiengesellschaft Verfahren, Steuerung und Kraftfahrzeug
US11080105B1 (en) 2020-11-18 2021-08-03 Cdk Global, Llc Systems, methods, and apparatuses for routing API calls
US11514021B2 (en) 2021-01-22 2022-11-29 Cdk Global, Llc Systems, methods, and apparatuses for scanning a legacy database
US11803535B2 (en) 2021-05-24 2023-10-31 Cdk Global, Llc Systems, methods, and apparatuses for simultaneously running parallel databases
DE102022113682A1 (de) 2022-05-31 2023-11-30 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Computerimplementiertes Verfahren zur Übermittlung von Informationen über einen Scheinwerfer eines Kraftfahrzeugs mit mehreren Lichtquellen
US11983145B2 (en) 2022-08-31 2024-05-14 Cdk Global, Llc Method and system of modifying information on file

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19725915A1 (de) * 1997-06-19 1999-01-28 Daimler Benz Ag Rechnergestützte Diagnoseeinrichtung und Diagnoseverfahren für elektronisch gesteuerte Systeme
US6181994B1 (en) * 1999-04-07 2001-01-30 International Business Machines Corporation Method and system for vehicle initiated delivery of advanced diagnostics based on the determined need by vehicle
EP1087343A1 (de) * 1999-09-24 2001-03-28 Renault Verfahren und Vorrichtung zur Fahrzeugferndiagnose über ein Kommunikationsnetz
EP1205883A1 (de) * 2000-11-10 2002-05-15 Renault Diagnostische Hilfsvorrichtung für ein Kraftfahrzeug und zugehöriges Verfahren
DE10145906A1 (de) * 2001-09-18 2003-04-10 Bosch Gmbh Robert Verfahren zur Durchfühung einer Ferndiagnose bei einem Kraftfahrzeug, Fahrzeugdiagnosemodul und Servicecenter

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19725915A1 (de) * 1997-06-19 1999-01-28 Daimler Benz Ag Rechnergestützte Diagnoseeinrichtung und Diagnoseverfahren für elektronisch gesteuerte Systeme
US6181994B1 (en) * 1999-04-07 2001-01-30 International Business Machines Corporation Method and system for vehicle initiated delivery of advanced diagnostics based on the determined need by vehicle
EP1087343A1 (de) * 1999-09-24 2001-03-28 Renault Verfahren und Vorrichtung zur Fahrzeugferndiagnose über ein Kommunikationsnetz
EP1205883A1 (de) * 2000-11-10 2002-05-15 Renault Diagnostische Hilfsvorrichtung für ein Kraftfahrzeug und zugehöriges Verfahren
DE10145906A1 (de) * 2001-09-18 2003-04-10 Bosch Gmbh Robert Verfahren zur Durchfühung einer Ferndiagnose bei einem Kraftfahrzeug, Fahrzeugdiagnosemodul und Servicecenter

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LUKA J ET AL: "Mobile diagnosis Yof vehicle mechatronic systems", VEHICLE ELECTRONICS CONFERENCE, 1999. (IVEC '99). PROCEEDINGS OF THE IEEE INTERNATIONAL CHANGCHUN, CHINA 6-9 SEPT. 1999, PISCATAWAY, NJ, USA,IEEE, US, 6 September 1999 (1999-09-06), pages 215 - 220, XP010375901, ISBN: 0-7803-5296-3 *

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1583039A1 (de) * 2004-03-30 2005-10-05 Scania CV AB Fahrzeug und Verfahren für ein Fahrzeug
WO2006040560A1 (en) * 2004-10-15 2006-04-20 Black Spot Interactive Ltd Apparatus and method for monitoring the usage status of an asset
WO2006071457A1 (en) * 2004-12-29 2006-07-06 Snap-On Incorporated Device and method for producing computer readable formatted output
DE102005011748A1 (de) * 2005-03-11 2006-09-14 Volkswagen Ag Verfahren und Anordnung zum Diagnostizieren von eingebetteten Systemen
US8229620B2 (en) 2005-06-03 2012-07-24 Robert Bosch Gmbh Method for model-based diagnosis of a mechatronic system
WO2006128788A1 (de) * 2005-06-03 2006-12-07 Robert Bosch Gmbh Verfahren zur modellbasierten diagnose eines mechatronischen systems
CN101189500B (zh) * 2005-06-03 2010-05-19 罗伯特·博世有限公司 基于模型地诊断机械电子系统的方法
KR101131344B1 (ko) * 2005-06-03 2012-04-04 로베르트 보쉬 게엠베하 메커트로닉스 시스템의 모델에 기초한 진단 방법
WO2007098781A1 (de) * 2006-02-28 2007-09-07 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur drahtlosen fehlerbeseitigung an einem kraftfahrzeug
EP2278424A1 (de) * 2009-07-21 2011-01-26 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Diagnosesystems für ein Kraftfahrzeug und Diagnosesystem zur Ausführung des Verfahrens
CN102023621A (zh) * 2010-08-20 2011-04-20 上海自动化仪表股份有限公司 车载接口设备及其数据采集处理方法
CN102981496A (zh) * 2012-11-14 2013-03-20 深圳市元征科技股份有限公司 基于车辆专业诊断的远程监控及数据存储方法
CN102981496B (zh) * 2012-11-14 2015-01-21 深圳市元征科技股份有限公司 基于车辆专业诊断的远程监控及数据存储方法
WO2014202269A1 (de) * 2013-06-19 2014-12-24 Robert Bosch Gmbh Modul und system zur fahrzeugdiagnose
CN110032166A (zh) * 2013-06-19 2019-07-19 罗伯特·博世有限公司 用于进行车辆诊断的模块和系统
CN106289794A (zh) * 2015-05-25 2017-01-04 上海汽车集团股份有限公司 整车测试的数据处理方法和装置
CN106289794B (zh) * 2015-05-25 2019-08-13 上海汽车集团股份有限公司 整车测试的数据处理方法和装置
FR3081594A1 (fr) * 2018-05-23 2019-11-29 Psa Automobiles Sa Procede de diagnostic d’un vehicule automobile a distance avec communication internet.
CN113325831A (zh) * 2021-06-24 2021-08-31 江铃汽车股份有限公司 一种平台化的汽车刷写诊断的网关路由方法

Also Published As

Publication number Publication date
US20070100519A1 (en) 2007-05-03
DE10323384A1 (de) 2004-12-16

Similar Documents

Publication Publication Date Title
WO2004104604A1 (de) Diagnosesystem
EP1298005B1 (de) Verfahren zur Bereitstellung eines Wartungsalgorithmus
DE10007218B4 (de) Verfahren zur Ereignisinterpretation und Ausgabe von Bedienhinweisen in Kraftfahrzeugen
EP2425333B1 (de) Verfahren zur aktualisierung von softwarekomponenten
DE112006003591B4 (de) Verfahren zum Bereitstellen einer Fahrzeuginformation durch eine Fahrzeug - Email - Benachrichtigung unter Verwendung von Vorlagen
WO2004104836A2 (de) Telediagnose-viewer
EP1597643B1 (de) Vorrichtung und verfahren zur modellbasierten on-board-diagnose
DE112009000439T5 (de) Fahrzeuginformationsaufzeichnungsvorrichtung, Fahrzeuginformationskommunikationssystem und Fahrzeuginformationskommunikationsverfahren
EP1516291A1 (de) Verfahren und vorrichtung für einen fahrzeugbezogenen telematikdienst
EP2013060A1 (de) Diagnosesystem mit wlan übertragungsmodul und implementiertem diagnosekurztest
DE102005015664A1 (de) Diagnosesystem zur Bestimmung einer gewichteten Liste möglicherweise fehlerhafter Komponenten aus Fahrzeugdaten und Kundenangaben
DE102005044236B4 (de) Diagnosegerät
DE102004042002A1 (de) Verbesserte Reparaturverifikation für elektronische Fahrzeugsysteme
WO2018219887A1 (de) Wartung eines nutzfahrzeugs
WO2003016856A2 (de) Kommunikationsverfahren und kommunikationsmodul
DE102008040796A1 (de) Verfahren zur Ermittlung eines Fehlers in einer Baugruppe
DE102015214157A1 (de) Verfahren, System und von einem Computer lesbares Aufzeichnungsmedium für das Steuern eines abnormalen Zustands des Fahrzeugs
DE19725915A1 (de) Rechnergestützte Diagnoseeinrichtung und Diagnoseverfahren für elektronisch gesteuerte Systeme
DE102021002302A1 (de) Verfahren zur Ablaufplanung durchzuführender Testprozesse
DE10243093B4 (de) Vorrichtung und Verfahren zum System-Check von Fahrzeugen
EP1163645A1 (de) Vorrichtung und verfahren zur insbesondere mobilen datenerfassung
DE10028870A1 (de) Elektronische Wagenprüfkarte
DE102019206189B4 (de) Kommunikationssystem mit einem Kraftfahrzeug und einer Servervorrichtung, Kraftfahrzeug, und Servervorrichtung
DE19959140B4 (de) Fehlerdiagnosesystem für Kraftfahrzeuge
DE102019208134A1 (de) Off-Board-Diagnosevorrichtung, Off-Board-Diagnosesystem und Verfahren für eine vorbeugende Wartung

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
WWE Wipo information: entry into national phase

Ref document number: 2007100519

Country of ref document: US

Ref document number: 10558081

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10558081

Country of ref document: US