WO2006105930A1 - Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben - Google Patents

Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben Download PDF

Info

Publication number
WO2006105930A1
WO2006105930A1 PCT/EP2006/003049 EP2006003049W WO2006105930A1 WO 2006105930 A1 WO2006105930 A1 WO 2006105930A1 EP 2006003049 W EP2006003049 W EP 2006003049W WO 2006105930 A1 WO2006105930 A1 WO 2006105930A1
Authority
WO
WIPO (PCT)
Prior art keywords
error
diagnostic
diagnostic system
focus
components
Prior art date
Application number
PCT/EP2006/003049
Other languages
English (en)
French (fr)
Inventor
Martin Konieczny
Harald Renninger
Moritz SCHULÈ
Marc Schuller
Darko Tislaric
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
Publication of WO2006105930A1 publication Critical patent/WO2006105930A1/de

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0275—Fault isolation and identification, e.g. classify fault; estimate cause or root of failure
    • G05B23/0278—Qualitative, e.g. if-then rules; Fuzzy logic; Lookup tables; Symptomatic search; FMEA

Definitions

  • the invention relates to a computer-aided diagnostic system that generates a weighted list of possibly defective motor vehicle components with the aid of a diagnostic program from vehicle data and customer information.
  • the identification of the possible error candidates takes place via an evaluation of a rule table reflecting the diagnostic knowledge.
  • the additional evaluation of vehicle functions possibly affected by the error candidates also extends the troubleshooting space.
  • the service technician can restrict troubleshooting to selected fault codes or functions by setting a focus within the determined troubleshooting space. Only the possible candidates for the selected error codes or functions will then be considered.
  • the error candidates belonging to this focus set are weighted by offsetting several error probabilities for error codes, components and affected functions or error symptoms.
  • known bugs which are coupled error codes, possibly also symptoms that always occur together, can be used for the billing.
  • the characteristic of the system diagnosis is the mapping of the system to be diagnosed into at least one physical-mathematical model that can be implemented and processed with computer assistance.
  • the modeling comprises a structural model and an impact model, which is often referred to as a behavioral model.
  • the structure model depicts the physical relationships of the individual components of the technical system, and the behavioral model maps the functions of the individual components of the system.
  • a knowledge base which is essentially a rule table from If / then conditions, which in turn can be mapped to data tuples, the diagnostic knowledge relevant for the system diagnostics is stored. With the system diagnostics a fault detection and by recourse to the knowledge base a computer-aided troubleshooting can be carried out.
  • System diagnostics has two major disadvantages.
  • the modeling is extremely expensive for larger technical systems, such as a motor vehicle, if all possible causes of faults are to be controlled by the system.
  • Even more difficult to handle in system diagnostics are ambiguous system states, eg if a recorded error code can have several causes that can not be further processed by the system diagnostics due to the lack of sufficient error environment data or insufficient information about the current system state.
  • the system diagnostics then stops at this point without diagnostic result.
  • Another disadvantage of the system diagnosis is its basic unsuitability for the processing of experience of the service technician. Nor can Customer information on defective functions or on intact functions in the diagnostic process.
  • Diagnostic systems of the aforementioned type have the further disadvantage that they very quickly become very complex and the necessary modeling effort, calculation effort and calculation effort for larger technical systems increases exponentially with the number of error possibilities of the individual components of the overall system.
  • all possible checks must be mapped into a static audit trail for the diagnosis.
  • in reality in systems with multiple interdependent components, there are a plethora of ways in which individual sub-checks of individual components can be performed. With 5 components already theoretically 5 faculties result in different test procedures, which would all have to be represented by a static test tree. The efficiency of the diagnostic methods therefore decreases drastically with the number of possible errors.
  • the solution succeeds mainly with an interactively operating diagnostic program, in which the service technician can set a focus for the further, automated troubleshooting by the diagnostic program within a troubleshooting space, which is initially defined by the diagnostic program, of the possibly identified components or functions.
  • Focusing can be done by limiting it to an error code or by restricting it to an impaired function or error symptom. After setting the focus becomes a limited focus amount, which is the selected focus possible error candidates selected.
  • the individual error candidates hereby - by offsetting different probabilities for the occurrence of an error code, for the probability of failure of a component or function and possibly for the presence of an error image - a weighting.
  • the diagnostic system has the additional possibility of processing error images.
  • Fault images here are combinations of several fault codes that are specific to the failure of a particular component or a small amount of components and so can provide a direct indication of the defective component (s).
  • the error images can be formed from a combination of active and inactive error codes and symptoms.
  • the non-active error codes can provide particularly valuable information on non-defective components and thus limit the number of possible error candidates.
  • a new focus can be set by the service technician and thus a new focus set with weighted error candidates can be generated.
  • the symptoms and error codes affected by this component can be inferred for the presence of a multiple error. Again, this can be done by setting the focus again On the post-declared symptoms or error codes the search will be restarted.
  • a new focus can also be offered very specifically to the service technician.
  • neighborhood relationships of cause sets or candidate sets e.g. of error codes, be exploited.
  • the search can therefore be extended to other neighboring causes.
  • candidate sets that were not explained by a found error may be suggested as a new focus.
  • the knowledge base of the diagnostic system can be expanded with field experience from the operation of motor vehicles in order to optimize the diagnostic process.
  • the error weights g (Kj) can be adapted.
  • more error images FB can be detected and added via field data evaluation, which can then be used immediately in a subsequent diagnostic session application.
  • the service technician is given an indication of the presence of a phantom error.
  • a reliability variable for example P (FC
  • the service technician By weighting the error candidates within the focus set, the service technician is given a prioritization that gives him an indication of which of the possible components is most likely to be defective. This provides the service technician with information about which components he should first check in order to actually find a defective component as quickly as possible.
  • the system automatically offers at least one check for each component of the candidate list.
  • Fig. 1 A computerized diagnostic system for a
  • FIG. 2 shows a modular block diagram of the diagnostic system according to the invention with data flow relationships between the individual program modules and the input and output interfaces of the diagnostic system;
  • Figure 1 a situation is shown schematically, as it is known today in motor vehicle workshops.
  • a computer-aided diagnostic tester 1 is connected via a standardized diagnostic interface 2 to the communication network 3 for the control units 4 in the motor vehicle.
  • Known diagnostic testers are z.
  • the DAS system from DaimlerChrysler or the BMW DIS system.
  • the control units 4 installed in the motor vehicle are in communication with each other, for example via a data bus.
  • a common data bus in motor vehicles is the so-called CAN bus (for Controller Area Network).
  • CAN bus for Controller Area Network
  • error memory In the context of the self-diagnosis of the control units errors identified in coded form as so-called error codes by the control unit software in specially reserved memory areas, so-called error memory, with the help of the diagnostic routine in the control units.
  • error memory In the schematic representation of FIG. 1, these reserved, non-volatile memory areas are designated FS (for error memory).
  • FS for error memory
  • the standard for the Keyword Protocol 2000 includes two different application options. On the one hand, the standard stipulates that the communication between the diagnostic tester and the control units is effected via a gateway 5, which is eg. B. binds the motor vehicle CAN bus to the diagnostic interface 2, or takes place, as usual, the error memory of the control units via the so-called. K and L lines and read via the normalized diagnostic interface 2 directly into the diagnostic tester and stored can be.
  • a gateway 5 which is eg. B. binds the motor vehicle CAN bus to the diagnostic interface 2, or takes place, as usual, the error memory of the control units via the so-called.
  • K and L lines and read via the normalized diagnostic interface 2 directly into the diagnostic tester and stored can be.
  • FIG. 1 shows the more modern form of access via a CAN bus and thus via a gateway.
  • the invention is of concern only that there is at least one way to be able to read the error memory of the control units with a diagnostic tester.
  • the transmitted contents of the control device memory, in particular error codes and status data of the control devices are further processed in a diagnostic session with an implemented diagnostic program.
  • the diagnostic program also includes the option of manually inputting further information that is important for a diagnosis via a computer workstation as a human-machine interface.
  • FIG. 2 shows a block diagram of the most important program modules and realized with these program modules Functionally a diagnostic system according to the invention.
  • the individual program modules are integrated into a higher-level sequence control of the entire diagnostic system. This sequence control takes over the call of the individual program modules at the respectively necessary time.
  • the diagnostic system processes error codes FC and inputs by a service technician as input variables.
  • the service technician makes his inputs from a VDU workstation 200, which is typically equipped with a screen and a computer keyboard, each connected to the computer system 201 of the diagnostic system. Via a further interface 202, the computer system can be connected to the motor vehicle to be diagnosed. About the OBD socket (On Board Diagnosis), the control units contained in the motor vehicle can be addressed.
  • OBD socket On Board Diagnosis
  • the self-diagnosis routines of the control units can be started and thereby functional test of the individual control units are started and it can be accessed and read current system state data from the motor vehicle.
  • One possibility of the technical realization was discussed in connection with FIG.
  • the diagnostic program implemented on the computer system is characterized among other things by a modular structure.
  • the programming and the configuration of the diagnostic system are structured.
  • a first program module 210 according to its function called rule table evaluation, retrieved from the motor vehicle data, such as error codes and system status data to the individual components installed in the motor vehicle, read and processed.
  • the further processing includes checking of rule tables stored in a knowledge base 211.
  • the rule tables contain the diagnostic knowledge relevant for the technical system to be diagnosed. This knowledge is stored, for example, in compressed form in data tuples.
  • the data tuples depict the relationships between the information contained in them.
  • a data tuple is stored for each diagnostic rule.
  • a data tuple consists in each case of a component identifier Ki, an error code FCi, a symptom sympi as an indication of an affected technical function or for the possible fault effect observed by the driver, and a system status Stat.
  • the rule table evaluation then takes place in such a way that in the totality of all stored data tuples it is checked which data tuples contain the read code (s) and which components Ki and functions / error symptoms Sympi are named in the identified data tuples and thus can be affected by the observed error FCi.
  • the component identifications found in this way are recorded and combined into a first quantity of error candidates and stored.
  • the troubleshooting space formed by the first candidate set is further developed.
  • the possible sources of error are now extended by the relevant functions that may be involved in the motor vehicle.
  • the rule tables are searched again, this time not according to detected error codes, but according to the possibly already affected by the error codes components Ki.
  • the components that are to be affected are the possibly affected Sympi functions. These two quantities do not have to be identical. Because it is possible that an error code refers to a component that is relevant for several functions.
  • the result of this second pass through the knowledge base is a supplemented candidate list 214, which now also contains possibly faulty functions in addition to the possibly faulty components.
  • On-screen workstation 200 performed a query 215 and displayed whether for further processing, the already determined error codes or the determined possibly affected functions to be displayed. About the difference is related below with the Described description of Figure 3 in more detail.
  • the service technician is offered the opportunity to set a focus for the further diagnostic procedure. Depending on the selected display, the focus is set by either selecting a displayed error code or a displayed, suspicious function Sympi by means of graphical menu control, and using it for further processing by the diagnostic program. If the focus is set, further data processing is restricted to this focus. This means that not all detected error codes, suspicious candidates or suspicious functions are considered, but only those that fall under the chosen focus.
  • the individual error candidates are subjected to a weighting in a further program module or method step 217.
  • the probabilities of the error codes FCi For the weighting, the probabilities of the error codes FCi, the probability of the occurrence of sympi and possibly the probability of the occurrence of error images must be calculated. For this purpose, probabilities must be provided which specify with which certainty a defective component or a candidate Ki an error code (P (FCi
  • the relative error weighting g (Kj) of a component itself is needed. This information is needed to calculate the prioritized or weighted candidate list.
  • the conditional probabilities are easy to estimate. Usually they are set to "1.” However, insecure symptoms or error codes can sometimes assume values of less than 1.
  • the error weights g (Kj) can be derived from experience eg can be selected between one and one hundred and represent a relative failure characteristic.
  • the current field events can also be taken into account via these error weights g (Kj) by adapting these weights by calculating error frequencies.
  • All probabilities and error weights are stored in the database of the diagnostic system 218. Appropriately, these can be stored and fed together with the component list, the function or sympotom list and the error image list. These lists are created in the construction of a motor vehicle and therefore need only be supplemented by the experience with regard to the conditional Wahrscheointechniken and the error weights. Expediently, the data is model-specific. However, cross-product databases can also be created and used. For cross-database databases, however, the possibility of a series-specific selection, e.g. be kept in the form of an upstream master table.
  • G is a scaling quantity and is defined in a preparation step or by a calculation, eg as the sum of all weights g (KJ).
  • the calculation of a prioritized or weighted candidate list 219 can be initiated and finally displayed on the display of the Computer workstation 200 are output.
  • the a posteriori error probability or priority Prio (Ki) of a component Ki results from the following product:
  • This priority is still not standardized and can alternatively be normalized by dividing by the sum of all candidate priorities.
  • the data type is -double- to use because of the possibility that the prioritization value of a candidate can take a very small floating-point value. It must be checked after each calculation that the prioritization value of a candidate within the focus set does not become 0. Should this nevertheless occur, the smallest, possible, positive numerical value must be used for the relevant prioritization value for the data format double.
  • the calculation of the weighted candidate list can be run through several times within a diagnostic session. This is e.g. necessary if the review of the candidates from the first focus quantity by the service technician has not led to a positive result. In this case, the service technician must be able to create a different candidate list by choosing a different focus. The same applies to assumptions of multiple errors.
  • a short test 310 is first started. With this short test, the self-diagnostic routines of the control units installed in the motor vehicle are started and then, in a following method step 311, the error memories of the control units are read out and a list of all actively set error codes possibly generated with the associated error environment data. Subsequently, in a further method step 312, a rule is selected by means of a master table which is valid for the diagnosis of the motor vehicle to be examined.
  • the identification of the vehicle and the identification of the valid control tables can in this case, for example, via the vehicle identification number respectively.
  • the possibly affected components, further functions and error patterns are determined for the reported error codes and for the reported malfunctions.
  • a decision step 315 the service technician is given the opportunity to continue the diagnostic session with an error code-based display or a function-based display, after the error codes already determined and the malfunctions identified have been displayed to him.
  • the function-based method of operation has particular advantages if the service technician intends to include customer information on functioning and non-functioning subsystems in the diagnostic process.
  • the function-based representation in particular allows the processing of only symptomatic known malfunctions, as is usually the case with customer complaint.
  • the rules to be evaluated which fired in the runs of the rules table evaluation according to steps 313 and 314, ie containing either the observed error code or an observed error symptom, may be compressed in an alternative further method step for further calculations .
  • syntax constituents and semantic constituents of the diagnostic rules can be derived from the knowledge base eliminated and the diagnostic rules are compressed into number tuples.
  • the possibly affected defect images can be determined for the fault codes or fault symptoms that are in focus and included in the further calculation.
  • the diagnostic flow proceeds to step 319 where the error probabilities for components and thus the prioritization or weighting of the suspected components are calculated. If the prioritization is fixed, the prioritized error candidates are displayed to the service technician along with their prioritization. The service technician then checks the individual components or candidates at his option. The result of its check decides in a further query step 321 whether the diagnostic procedure and thus the diagnostic program jump back to decision step 315 or not. If the error was found, the diagnostic session ends. If no error has been found, the diagnostic session is continued and the service technician has the option to set a different focus in the next run.
  • a function tree is displayed in the next step 322 in which the suspect functions are optically highlighted become.
  • the service technician can also use the function-based representation in a following method step 323 set a focus for the further diagnostic procedure.
  • the control tables of the diagnostic system are evaluated a second time after setting the focus in the following method step 324. This is necessary in order to supplement the troubleshooting space for the suspicious components and to build them up as completely as possible. In one function, several components and their interaction are usually used.
  • the components were only determined using the error codes. Operation via function-based focussing also allows the troubleshooting space to be extended to those components that can be identified by the function and that have not previously been identified by an error code.
  • the diagnostic program may then continue with the alternative data compression method step 317 or with the error determination procedure step 318.

Landscapes

  • Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Vehicle Cleaning, Maintenance, Repair, Refitting, And Outriggers (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

Die Erfindung betrifft ein rechnergestütztes Diagnosesystem, das mit Hilfe eines Diagnoseprogramms aus Fahrzeugdaten und Kundenangaben eine gewichtete Liste der möglicherweise fehlerhaften Kraftfahrzeugkomponenten erstellt. Die Identifikation der möglichen Fehlerkandidaten erfolgt über eine Auswertung einer das Diagnosewissen abbildenden Regeltabelle. Durch die zusätzliche Auswertung von durch die Fehlerkandidaten möglicherweise ebenfalls betroffenen Fahrzeugfunktionen wird der Fehlersuchraum erweitert. Der Servicetechniker kann durch Setzen eines Fokus innerhalb des ermittelten Fehlersuchraums, die Fehlersuche auf ausgewählte Fehlercodes oder Funktionen einschränken. Es werden dann nur die zu den ausgewählten Fehlercodes oder Funktionen möglichen Kandidaten weiter betrachtet. Die zu dieser Fokusmenge gehörenden Fehlerkandidaten werden durch Verrechnung mehrerer Fehlerwahrscheinlichkeiten für Fehlercodes, Komponenten und betroffene Funktionen gewichtet. Alternativ können für die Verrechnung noch bekannte Fehlerbilder, das sind gekoppelte Fehlercodes, die immer gemeinsam auftreten, hinzugezogen werden .

Description

Diagnosesystem zur Bestimmung einer gewichteten Liste möglicherweise fehlerhafter Komponenten aus Fahrzeugdaten und
Kundenangaben
Die Erfindung betrifft ein rechnergestütztes Diagnosesystem, das mit Hilfe eines Diagnoseprogramms aus Fahrzeugdaten und Kundenangaben eine gewichtete Liste der möglicherweise fehlerhaften Kraftfahrzeugkomponenten erstellt. Die Identifikation der möglichen Fehlerkandidaten erfolgt über eine Auswertung einer das Diagnosewissen abbildenden Regeltabelle. Durch die zusätzliche Auswertung von durch die Fehlerkandidaten möglicherweise ebenfalls betroffenen Fahrzeugfunktionen wird der Fehlersuchraum erweitert. Der Servicetechniker kann durch Setzen eines Fokus innerhalb des ermittelten Fehlersuchraums, die Fehlersuche auf ausgewählte Fehlercodes oder Funktionen einschränken. Es werden dann nur die zu den ausgewählten Fehlercodes oder Funktionen möglichen Kandidaten weiter betrachtet. Die zu dieser Fokusmenge gehörenden Fehlerkandidaten werden durch Verrechnung mehrerer Fehlerwahrscheinlichkeiten für Fehlercodes, Komponenten und betroffene Funktionen bzw. FehlerSymptomen gewichtet. Alternativ können für die Verrechnung noch bekannte Fehlerbilder, das sind gekoppelte Fehlercodes, ggf. auch Symptome, die immer gemeinsam auftreten, hinzugezogen werden. Ein Beispiel für eine Systemdiagnose ist in der deutschen Patentanmeldung DE 195 23 483 Al offenbart. Kennzeichen der Systemdiagnose ist das Abbilden des zu diagnostizierenden Systems in mindestens ein physikalisch-mathematisches Modell, das rechnergestützt implementiert und verarbeitet werden kann. In der DE 195 23 483 Al umfasst die Modellbildung ein Strukturmodell und ein Wirkungsmodell, das oft auch als Verhaltensmodell bezeichnet wird. Mit dem Strukturmodell werden die physikalischen Zusammenhänge der einzelnen Komponenten des technischen Systems abgebildet und mit dem Verhaltensmodell werden die Funktionen der einzelnen Komponenten des Systems abgebildet. In einer Wissensbasis, die im Wesentlichen eine Regeltabelle aus Wenn/dann Konditionen, die sich wiederum auf Datentupel abbilden lassen, ist, ist das für die Systemdiagnose relevante Diagnosewissen abgespeichert. Mit der Systemdiagnose kann eine Fehlererkennung und durch Rückgriff auf die Wissensbasis eine rechnergestützte Fehlersuche durchgeführt werden.
Die Systemdiagnose hat zwei entscheidende Nachteile. Die Modellbildung ist für größere technische Systeme, wie z.B. ein Kraftfahrzeug äußerst aufwendig, wenn alle möglichen Fehlerursachen von dem System beherrscht werden sollen. Noch schwieriger zu handhaben sind in der Systemdiagnose mehrdeutige Systemzustände, wenn z.B. ein aufgenommener Fehlercode mehrere Ursachen haben kann, die mangels ausreichender Fehlerumgebungsdaten oder mangels ausreichender Informationen über den aktuellen Systemzustand, von der Systemdiagnose nicht weiter verarbeitet werden können. Die Systemdiagnose bricht dann an dieser Stelle ohne Diagnoseergebnis ab. Ein weiterer Nachteil der Systemdiagnose ist ihre prinzipielle Nichteignung für die Verarbeitung von Erfahrungswissen des Servicetechnikers . Ebenso wenig können Kundenangaben zu defekten Funktionen oder zu intakten Funktionen in den Diagnoseprozess einfließen.
Diagnosesysteme der vorgenannten Art haben den weiteren Nachteil, dass sie sehr schnell sehr komplex werden und der notwendige Modellierungsaufwand, Bedatungsaufwand und Berechnungsaufwand für größere technische Systeme exponentiell mit der Anzahl der Fehlermöglichkeiten der einzelnen Komponenten des Gesamtsystems zunimmt. Außerdem müssen für die Diagnose alle möglichen Prüfungen in einen statischen Prüfsehrittbaum abgebildet werden. In der Realität ergibt sich bei Systemen mit mehreren von einander abhängigen Komponenten eine Unmenge von Möglichkeiten, in welcher Reihenfolge einzelne Teilprüfungen von einzelnen Komponenten durchgeführt werden können. Bei 5 Komponenten ergeben sich bereits theoretisch 5 Fakultät unterschiedliche Prüfablaufe, die alle durch einen statischen Prüfbaum abgebildet werden müssten. Die Effizienz der Diagnoseverfahren nimmt daher mit Anzahl der Fehlermöglichkeiten drastisch ab.
Man hat deshalb nach effizienteren Möglichkeiten gesucht, ein Diagnosesystem aufzubauen.
Eine Möglichkeit den Diagnoseablauf zu verbessern ist in der europäischen Patentschrift EP 1 069 487 Bl beschrieben. Parallel zum Reparaturfortschritt kann von einem Servicetechniker an entscheidenden Stellen des Prüfschrittbaumes gesichertes Wissen, so genannte Evidenz, abgefragt werden und in das Diagnosesystem eingerechnet werden. Damit müssen nicht mehr alle Fehlermöglichkeiten und Prüfmöglichkeiten berechnet werden. Das Diagnoseverfahren kann umso effizienter werden je mehr Abfragen an geeigneter Stelle des Diagnoseablaufs systemseitig vorgesehen sind. Die Eingabe des evidenten Wissens erfolgt über eine Benutzer Schnittstelle, die durch ein Display und ein Eingabemenü gebildet wird.
Wünschenswert für die Fehlersuche mit zukünftigen Diagnosesystemen in Werkstätten ist die Kosteneffizienz der durchzuführenden Prüfungen. Ein schneller und effizienter Prüfungsablauf ist somit eine wünschenswerte Vorgabe an diese zukünftigen Diagnosesysteme.
Erfindungsgemäße Aufgabe ist es daher ein Diagnosesystem anzugeben, das eine sinnvolle Reduktion der Fehlersuche ermöglicht und das zudem in der Lage ist, eine ökonomisch sinnvolle Prüfungsreihenfolge für die Fehlersuche und Reparatur des zu prüfenden, technischen Systems vorzuschlagen.
Die Aufgabe wird gelöst mit einem Diagnosesystem und einem Diagnoseverfahren nach Anspruch 1. Weitere vorteilhafte Ausführungsformen sind in den Unteransprüchen und in der folgenden Beschreibung enthalten.
Die Lösung gelingt hauptsächlich mit einem interaktiv arbeitenden Diagnoseprogramm, bei dem der Servicetechniker, innerhalb eines von dem Diagnoseprogramm zunächst aufgespannten Fehlersuchraumes der als möglicherweise defekt identifizierten Komponenten oder Funktionen, einen Fokus für die weitere, automatisierte Fehlersuche durch das Diagnoseprogramm setzen kann. Das Setzen des Fokus kann hierbei durch Einschränkung auf einen Fehlercode oder durch Einschränkung auf eine beeinträchtigte Funktion bzw. Fehlersymptom erfolgen. Nach Setzen des Fokus wird eine eingeschränkte Fokusmenge, der zu dem gewählten Fokus möglichen Fehlerkandidaten ausgewählt. Die einzelnen Fehlerkandidaten erfahren hierbei - durch Verrechnung von verschiedenen Wahrscheinlichkeiten für das Auftreten eines Fehlercodes, für die Ausfallwahrscheinlichkeit einer Komponente oder einer Funktion und gegebenenfalls für das Vorliegen eines Fehlerbildes - eine Gewichtung.
In einer vorteilhaften Ausführungsform des erfindungsgemäßen Diagnosesystems verfügt das Diagnosesystem über die zusätzliche Möglichkeit Fehlerbilder zu verarbeiten. Fehlerbilder sind hierbei Kombinationen mehrerer Fehlercodes, die spezifisch sind für den Ausfall einer bestimmten Komponente bzw. einer kleinen Menge von Komponenten und so ein direkten Hinweis auf die defekte Komponente (n) liefern können. Die Fehlerbilder können hierbei aus einer Kombination von aktiven und nicht aktiven Fehlercodes und Symptomen gebildet werden. Hierbei können die nicht aktiven Fehlercodes besonders wertvolle Hinweise auf nicht defekte Komponenten liefern und so die Menge der möglichen Fehlerkandidaten einschränken.
In einer weiteren vorteilhaften Ausführungsform der Erfindung kann, wenn die Überprüfung der Fehlerkandidaten in der Fokusmenge ergeben hat, dass keine der untersuchten Komponenten defekt war, ein neuer Fokus durch den Servicetechniker gesetzt werden und damit eine neue Fokusmenge mit gewichteten Fehlerkandidaten erzeugt werden.
In einer weiteren vorteilhaften Ausführung der Erfindung kann nach Auffinden einer defekten Komponente durch Nacherklären der von dieser Komponente betroffenen Symptome und Fehlercodes auf Vorliegen eines Mehrfachfehlers geschlossen werden. Auch in diesem Fall kann durch neues Setzen des Fokus auf die nacherklärten Symptome oder Fehlercodes die Suche wieder gestartet werden.
In einer weiteren vorteilhaften Ausführungsform der Erfindung kann z.B. im Fall, dass kein Fehler gefunden wurde, ein neuer Fokus auch sehr gezielt dem Servicetechniker angeboten werden. Hierzu können Nachbarschaftsbeziehungen von Ursachenmengen bzw. Kandidatenmengen, z.B. von Fehlercodes, ausgenutzt werden. Die Suche kann also gezielt auf weitere benachbarte Ursachenmengen ausgedehnt werden. Im Fall von Mehrfachfehlern können Kandidatenmengen, die nicht durch einen gefundenen Fehler erklärt wurden, als neuer Fokus vorgeschlagen werden.
In einer weiteren vorteilhaften Ausführungsform des Diagnosesystems kann die Wissensbasis des Diagnosesystems mit Felderfahrungen aus dem Betrieb von Kraftfahrzeugen erweitert werden, um damit den Diagnoseablauf zu optimieren. Über Felderfahrung, z.B. Fehlerhäufigkeiten, können die Fehlergewichte g(Kj) adaptiert werden. Weiterhin können über Felddatenauswertung weitere Fehlerbilder FB erkannt und hinzugefügt werden, die dann sofort in einer folgenden Diagnosesitzung Anwendung finden können.
In einer weiteren vorteilhaften Ausführungsform des Diagnosesystems wird dem Servicetechniker ein Hinweis auf Vorliegen eines Phantomfehlers gegeben. Dazu müssen für Fehlercodes, Fehlerbilder und Symptome z.B. in Form eines Bits oder einer weiteren Wahrscheinlichkeit eine Zuverlässigkeitgröße -z.B. P (FC | not Kj)- bedatet sein. Diese Zuverlässigkeit sagt aus, ob der betreffende Fehlercode (ebenso Fehlerbild, Symptom) auch ohne physikalischen Fehlergrund auftreten kann. Dann werden, falls durch weiteres Prüfen kein Fehler im Fokus gefunden wird, die Zuverlässigkeiten der für die priorisierten Kandidatenliste verrechneten Größen geprüft. Sind alle verwendeten Informationen in diesem Sinn nicht zuverlässig bzw. sicher, kann auch ein Phantomfehler vorliegen.
Mit der Erfindung werden hauptsächlich die folgenden Vorteile erzielt:
Durch die interaktive Ausgestaltung des Diagnosesystems, ist es möglich das Erfahrungswissen von Servicetechnikern während des Reparaturprozesses mit in den Reparatur- und Diagnoseprozess mit einfließen zu lassen. Durch Setzen eines Fokus innerhalb eines aufgespannten Fehlersuchraumes werden die zu verarbeitenden Informationen für den weiteren Diagnoseablauf drastisch reduziert. Hierdurch wird auch für. komplexe Systeme ein weiterer, automatisierter Diagnoseablauf möglich, der in einer Werkstattumgebung in akzeptablen Prozesszeiten zu einem weiterverwertbaren Ergebnis führt.
Durch Gewichtung der Fehlerkandidaten innerhalb der Fokusmenge wird dem Servicetechniker eine Priorisierung an die Hand gegeben, mit dem ihm ein Hinweis gegeben, wird, welche der möglichen Komponenten am wahrscheinlichsten defekt ist. Hierdurch werden dem Servicetechniker Hinweise gegeben, welche Komponenten er zuerst überprüfen soll, um eine defekte Komponente möglichst schnell tatsächlich aufzufinden. Das System bietet hierfür automatisch mindestens eine Prüfung für jede Komponente der Kandidatenliste an.
Im Folgenden wird das rechnergestützte Diagnosesystem anhand von graphischen Darstellungen näher erläutert. Dabei zeigen: Fig. 1 Ein rechnergestütztes Diagnosesystem für ein
Kraftfahrzeug, wie es an sich im Stand der Technik bekannt und eingeführt ist;
Fig. 2 ein modulares Blockschaltbild des erfindungsgemäßen Diagnosesystems mit Datenflusszusammenhängen zwischen den einzelnen Programmmodulen und den Ein- und Ausgabeschnittstellen des Diagnosesystems;
Fig. 3 Ein Ablaufdiagramm für das erfindungsgemäße Diagnoseprogramm;
In Figur 1 ist eine Situation schematisch dargestellt, wie sie heute in Kraftfahrzeugwerkstätten bekannt ist. Für die Diagnose eines Kraftfahrzeuges wird ein rechnergestützter Diagnosetester 1 über eine genormte Diagnoseschnittstelle 2 an das Kommunikationsnetzwerk 3 für die Steuergeräte 4 im Kraftfahrzeug angeschlossen. Bekannte Diagnosetester sind z. B. das System DAS von DaimlerChrysler oder das System BMW- DIS. Die im Kraftfahrzeug verbauten Steuergeräte 4 sind beispielsweise über einen Datenbus miteinander in Kommunikationsverbindung. Ein verbreiteter Datenbus in Kraftfahrzeugen ist hierbei der sog. CAN-Bus (für Controller Area Network) . Jedes der verbauten Steuergeräte im Kraftfahrzeug verfügt neben den Kommunikationsschnittstellen über die Fähigkeit zur Eigendiagnose. Im Rahmen der Eigendiagnose der Steuergeräte werden mit Hilfe der Diagnoseroutine in den Steuergeräten festgestellte Fehler in kodifizierter Form als sog. Fehlercodes von der Steuergeräte- Software in speziell reservierte Speicherbereiche, sog. Fehlerspeicher, geschrieben. In der schematischen Darstellung der Figur 1 sind diese reservierten, nicht flüchtigen Speicherbereiche als FS (für Fehler-Speicher) bezeichnet. Für die Kommunikation und für den Datenaustausch zwischen einem Diagnosetester und den im Kraftfahrzeug verbauten Steuergeräten hat sich ein Standard etabliert, der unter dem Namen Keyword-Protokoll 2000 bekannt ist und dessen Spezifizierung und Normierung sich in der ISO-Norm 14 230-3 wiederfindet. Mit den im Keyword-Protokoll 2000 verabredeten Steuerbefehlen und Datenformaten ist es möglich, über die Diagnoseschnittstelle die kodifizierten Inhalte der Fehlerspeicher der einzelnen Steuergeräte mit Hilfe des Diagnosetesters auszulesen und in das Rechensystem des Diagnosetester zu übertragen. Die Norm zu dem Keyword- Protokoll 2000 umfasst hierbei zwei verschiedene Applikationsmöglichkeiten. Zum einen sieht die Norm vor, dass die Kommunikation zwischen Diagnosetester und Steuergeräte über ein Gateway 5, das z. B. den Kraftfahrzeug-CAN-Bus an die Diagnoseschnittstelle 2 anbindet, erfolgt oder aber, dass wie früher üblich, die Fehlerspeicher der Steuergeräte über die sog. K- und L-Leitungen und über die normierte Diagnoseschnittstelle 2 direkt in den Diagnosetester ausgelesen und abgelegt werden können. In der schematischen Darstellung der Figur 1 ist die modernere Form des Zugriffs über einen CAN-Bus und damit über ein Gateway dargestellt. Für die Erfindung von Belang ist lediglich, dass es mindestens eine Möglichkeit gibt, die Fehlerspeicher der Steuergeräte mit einem Diagnosetester auslesen zu können. Im Diagnosetester werden die übertragenen Inhalte der Steuergerätespeicher insbesondere Fehlercodes und Zustandsdaten der Steuergeräte mit einem implementierten Diagnoseprogramm in einer Diagnosesitzung weiterverarbeitet. Das Diagnoseprogramm umfasst weiterhin die Möglichkeit über einen Bildschirmarbeitsplatz als Mensch-Maschine- Schnittstelle manuell weitere Informationen, die für eine Diagnose wichtig sind einzugeben.
Fig. 2 zeigt als Blockschaltbild die wichtigsten Programmmodule und mit diesen Programmmodulen realisierten Funktionell eines erfindungsgemäßen Diagnosesystems. Die einzelnen Programmmodule sind hierbei in eine übergeordnete Ablaufsteuerung des gesamten Diagnosesystems integriert. Diese Ablaufsteuerung übernimmt den Aufruf der einzelnen Programmmodule zum jeweils notwendigen Zeitpunkt. Als Eingangsgrößen werden von dem Diagnosesystem Fehlercodes FC und Eingaben durch einen Servicetechniker verarbeitet. Der Service Techniker macht seine Eingaben von einem Bildschirmarbeitsplatz 200, der typischer Weise mit einem Bildschirm und einer Computertastatur ausgestattet ist, die jeweils an das Computersystem 201 des Diagnosesystems angeschlossen sind. Über eine weitere Schnittstelle 202 ist das Computersystem an das zu diagnostizierende Kraftfahrzeug anschließbar. Über die OBD Steckdose (On Board Diagnosis) können die im Kraftfahrzeug enthaltenden Steuergeräte angesprochen werden. Es können dadurch die Fehlerspeicher der Steuergeräte ausgelesen werden, es können die Eigendiagnoseroutinen der Steuergeräte gestartet werden und dadurch Funktionstest der einzelnen Steuergeräte gestartet werden und es können aktuelle Systemzustandsdaten aus dem Kraftfahrzeug abgerufen und ausgelesen werden. Eine Möglichkeit der technischen Realisierung wurde im Zusammenhang mit Fig. 1 erörtert.
Die Verarbeitung der Systemdaten und der Ablauf des Diagnoseprogramms weichen jedoch bei der Erfindung entscheidend vom vorbekannten Stand der Technik ab. Die wichtigsten Unterschiede sind hierbei der interaktive Ablauf des Diagnoseprogramms und die damit verbundene Möglichkeit gezielte Diagnoseschwerpunkte zu bilden, in dem für die Fehlersuche ein oder mehrere Schwerpunkte, im folgenden Fokusse genannt, gesetzt werden können, und damit sowohl die Diagnosequalität als auch die Diagnosedauer verbessert werden können. Auf die programmtechnische Realisierung wird im Folgenden näher eingegangen:
Das auf dem Computersystem implementierte Diagnoseprogramm zeichnet sich unter anderem durch einen modularen Aufbau aus. Hierdurch werden unter anderem die Programmierung und die Bedatung des Diagnosesystems strukturiert. Mit einem ersten Programmmodul 210, entsprechend seiner Funktion genannt Regeltabellenauswertung, werden die aus dem Kraftfahrzeug abgerufenen Daten, wie Fehlercodes und Systemstatusdaten zu den einzelnen im Kraftfahrzeug verbauten Komponenten, eingelesen und weiterverarbeitet. Die Weiterverarbeitung beinhaltet ein Überprüfen von in einer Wissensbasis 211 abgespeicherten Regeltabellen. Die Regeltabellen beinhalten das für das zu diagnostizierende, technische System relevante Diagnosewissen. Dieses Wissen ist beispielsweise in komprimierter Form in Datentupeln abgelegt. Die Datentupel bilden hierbei die Zusammenhänge der in ihnen enthaltenen Informationen ab. Pro Diagnoseregel ist ein Datentupel abgelegt. Ein Datentupel besteht jeweils aus einer Komponentenkennung Ki, einem Fehlercode FCi, einem Symptom Sympi als Hinweis für eine betroffene technische Funktion bzw. für die vom Fahrer beobachtete mögliche Fehlerauswirkung, und einem Systemstatus Stat. Die Regeltabellenauswertung erfolgt dann derart, dass in der Gesamtheit aller abgelegten Datentupel nachgesehen wird, welche Datentupel den oder diejenigen eingelesenen Fehlercodes enthalten und welche Komponenten Ki und Funktionen/Fehlersymptome Sympi in den identifizierten Datentupeln genannt sind und damit von dem beobachteten Fehler FCi betroffen sein können. Die derart aufgefundenen Komponentenkennungen, werden festgehalten und zu einer ersten Fehlerkandidatenmenge zusammengefasst und abgespeichert. Diese Komponentenkennungen Ki geben einen Hinweis, welche Komponente oder auch welche Funktion des technischen Systems für den beobachteten Fehlercode oder für das beobachtete Fehlersymptom ursächlich sein kann. Ergebnis dieses ersten Durchforsten der Wissensbasis ist eine erste Menge verdächtiger Komponenten, die aufgrund der Identifikation über die Fehlercodes FCi ermittelt wurden.
In einem weiteren Verarbeitungsschritt bzw. Programmmodul 213 wird der durch die erste Kandidatenmenge gebildete Fehlersuchraum weiter aufgespannt. In einem zweiten Durchlauf durch die Wissensbasis werden nun die möglichen Fehlerquellen durch die relevanten Funktionen, die im Kraftfahrzeug betroffen sein können erweitert. Hierzu werden die Regeltabellen nochmals durchsucht, diesmal jedoch nicht nach festgestellten Fehlercodes, sondern nach den bereits über die Fehlercodes möglicherweise betroffenen Komponenten Ki . Zu den Komponenten werden die möglicherweise betroffenen Funktionen Sympi bestimmt. Diese beiden Mengen müssen nicht identisch sein. Denn es ist möglich, dass ein Fehlercode auf eine Komponente verweist, die für mehrere Funktionen relevant ist. Ergebnis dieses zweiten Durchlaufs durch die Wissensbasis ist eine ergänzte Kandidatenliste 214, die nun neben den möglicherweise fehlerhaften Komponenten auch die möglicherweise fehlerhaften Funktionen enthält.
An dieser Stelle angekommen, beginnt nun die Interaktionsmöglichkeit in den weiteren Ablauf des Diagnoseprogramms . Zunächst wird auf dem
Bildschirmarbeitsplatz 200 eine Abfrage 215 durchgeführt und angezeigt, ob für die weitere Verarbeitung die bereits ermittelten Fehlercodes oder die ermittelten möglicherweise betroffenen Funktionen angezeigt werden sollen. Über den Unterschied wird weiter unten im Zusammenhang mit der Beschreibung zu Figur 3 näher eingegangen. In beiden Fällen wird in einem weiteren Verfahrensschritt 216 dem Servicetechniker die Möglichkeit geboten, für den weiteren Diagnoseablauf einen Fokus zu setzen. Das Setzen des Fokus erfolgt hierbei je nach ausgewählter Anzeige, indem entweder ein angezeigter Fehlercode oder eine angezeigte, verdächtige Funktion Sympi per graphischer Menüsteuerung ausgewählt wird, und der weiteren Verarbeitung durch das Diagnoseprogramm zugrunde gelegt wird. Ist der Fokus gesetzt, wird die weitere Datenverarbeitung auf diesen Fokus beschränkt. D.h. es werden nicht mehr alle bereits ermittelten Fehlercodes, verdächtige Kandidaten oder verdächtige Funktionen betrachtet, sondern nur noch diejenigen, die unter den gewählten Fokus fallen.
Für die noch innerhalb des Fokus verdächtigen Komponenten Ki werden die einzelnen Fehlerkandidaten in einem weiteren Programmmodul bzw. Verfahrensschritt 217 einer Gewichtung unterzogen.
Für die Gewichtung müssen die Wahrscheinlichkeiten der Fehlercodes FCi, die Wahrscheinlichkeit für das Auftreten von Sympi und ggf. die Wahrscheinlichkeit für das Vorliegen von Fehlerbildern errechnet werden. Dazu müssen Wahrscheinlichkeiten bedatet sein, die angeben, mit welcher Sicherheit eine defekte Komponente bzw. ein Kandidat Ki einen Fehlercode (P(FCi|κj)), eine Fehlfunktion (P (Sympi | Kj )) oder ein Fehlerbild (P(FBi|κj)), verursachen. Außerdem wird die relative Fehlergewichtung g(Kj) einer Komponente selbst benötigt. Diese Informationen werden für die Berechnung der priorisierten, bzw. gewichteten Kandidatenliste benötigt. Die bedingten Wahrscheinlichkeiten lassen sich leicht schätzen. Meist sind sie auf „1" gesetzt. Unsichere Symptome oder Fehlercodes können aber mitunter Werte kleiner 1 annehmen. Die Fehlergewichte g(Kj) können aus Erfahrungswissen z.B. zwischen eins und hundert gewählt werden und stellen eine relative Ausfallkenngröße dar. In einer unten erläuterten vorteilhaften Ausführung kann auch über diese Fehlergewichte g(Kj) das aktuelle Feldgeschehen berücksichtigt werden, indem diese Gewichte über Verrechnung von Fehlerhäufigkeiten adaptiert werden.
Alle Wahrscheinlichkeiten und Fehlergewichte werden bei der Bedatung des Diagnosesystems in einer Datenbank 218 abgelegt. Zweckmäßiger Weise können diese sie zusammen mit der Komponentenliste, der Funktionen- oder Sympotomliste und der Fehlerbildliste abgelegt und bedatet werden. Diese Listen werden bei der Konstruktion eines Kraftfahrzeuges erstellt und brauchen daher nur um das Erfahrungswissen hinsichtlich der bedingten Wahrscheoinlichkeiten und der Fehlergewichte ergänzt werden. Zweckmäßigerweise erfolgt die Bedatung baureihenspezifisch. Es können jedoch auch Baureihen übergreifende Datenbanken erstellt und herangezogen werden. Bei Baureihen übergreifenden Datenbanken muss dann jedoch die Möglichkeit einer Baureihen spezifischen Auswahl, z.B. in Form einer vorgeschalteten Mastertabelle vorgehalten werden.
Aus den oben erläuterten Daten berechnen sich die Einzelgrößen wie folgt:
P(FCi) = ∑g(Kj)-P(FCi/Kj)/G; Kj verursacht FCi
P(Sympi) = ∑g(Kj) •P(SympiIKj)IG ; Kj verursacht Sympi
Kj verursacht FBi
Figure imgf000016_0001
Die drei errechneten Größen werden zur Erstellung der Kandidatenpriorisierung, weiter unten, benötigt. G ist eine Normierungsgroße und wird in einem Vorbereitungsschritt oder per Bedatung z.B. als Summe aller Gewichte g(KJ) festgelegt.
Nachdem die Wahrscheinlichkeiten der Fehlercodes P(FCi), der Fehlerbilder P(FBi) und der Fehlfunktionen P(Sγmpi) errechnet wurden und die Fokusmenge der Fehlerkandidaten feststeht, kann die Berechnung einer priorisierten bzw. gewichteten Kandidatenliste 219 angestoßen werden und schließlich auf dem Display des Bildschirmarbeitsplatzes 200 ausgegeben werden.
Die a posteriori Fehlerwahrscheinlichkeit oder Priorität Prio(Ki) einer Komponente Ki ergibt sich aus dem folgenden Produkt :
?rio(Ki) = (g(Ki)/G)- f\ P(FCj ] Ki)- Y[P(Sympk \ Ki) ■ Y[P(FBl \ Ki)
FCj aufgetreten Sympk aufgetreten FBl aufgetreten
Wobei gilt: P (FCi | K) =P (FCi) falls der Fehlercode FCi von einer Komponente K unabhängig ist und analog dazu P (Sympk I Ki)=P (Sympk) und P (FBl | Ki) =P (FBl) bei Unabhängigkeit von der jeweiligen Komponente.
Diese Priorität ist noch unnormiert und kann alternativ noch normiert werden indem durch die Summe aller Kandidatenprioritäten geteilt wird.
Für die einzelnen Berechnungen gelten noch folgende Bedingungen:
Als Datentyp ist -double- zu verwenden, da die Möglichkeit besteht, dass der Priorisierungswert eines Kandidaten einen sehr kleinen Fließkommawert annehmen kann. Es muss nach jeder Berechnung geprüft werden, dass der Priorisierungswert eines Kandidaten innerhalb der Fokusmenge nicht 0 wird. Sollte dies dennoch eintreten, so ist für den betreffenden Priorisierungswert der für das Datenformat double kleinste, mögliche, positive Zahlenwert zu verwenden.
Die Berechnung der gewichteten Kandidatenliste kann innerhalb einer Diagnosesitzung mehrfach durchlaufen werden. Das ist z.B. notwendig, wenn die Überprüfung der Kandidaten aus der ersten Fokusmenge durch den Servicetechniker zu keinem positiven Befund geführt hat. In diesem Fall muss der Servicetechniker die Möglichkeit haben, durch die Wahl eines anderen Fokus, eine andere Kandidatenliste zu erzeugen. Ähnliches gilt bei Vermutung auf Mehrfachfehler.
Nach dem vor beschriebenen wird nochmals anhand des Ablaufdiagramms von Fig. 3 auf das im DiagnoseSystem implementierte Diagnoseprogramm eingegangen. Zu Beginn einer Diagnosesitzung bei Vorliegen mindestens eines Fehlercodes, einer Fehlfunktion oder eines FehlerSymptoms Symp wird zunächst ein Kurztest 310 gestartet. Mit diesem Kurztest werden die Eigendiagnoseroutinen der im Kraftfahrzeug verbauten Steuergeräte gestartet und daraufhin in einem folgenden Verfahrensschritt 311, die Fehlerspeicher der Steuergeräte ausgelesen und eine Liste aller aktiv gesetzten Fehlercodes eventuell mit den zugehörigen Fehlerumgebungsdaten erzeugt. Anschließend wird in einem weiteren Verfahrensschritt 312 mittels einer Mastertabelle, die für das zu untersuchende Kraftfahrzeug für die Diagnose gültigen Regeltabellen ausgewählt. Die Identifikation des Fahrzeugs und die Identifikation der gültigen Regeltabellen kann hierbei z.B. über die Fahrzeugidentifikationsnummer erfolgen. In zwei weiteren Verfahrenschritten der Regeltabellenauswertung 313 und der Ermittlung relevanter Funktionen 314 werden zu den gemeldeten Fehlercodes und zu den gemeldeten Fehlfunktionen die möglicherweise betroffenen Komponenten, weitere Funktionen und Fehlerbilder ermittelt.
In einem Entscheidungsschritt 315 wird dem Servicetechniker, nachdem ihm die bereits ermittelten Fehlercodes und die ermittelten Fehlfunktionen angezeigt wurden, die Möglichkeit gegeben, die Diagnosesitzung mit einer Fehlercode basierten Anzeige oder einer funktionsbasierten Anzeige fortzusetzen. Die Funktionsbasierte Arbeitsweise hat insbesondere dann Vorteile, wenn der Servicetechniker Kundenangaben zu funktionierenden und nicht funktionierenden Teilsystemen mit in den Diagnoseprozess einfließen lassen will . Die funktionsbasierte Darstellung ermöglicht insbesondere die Verarbeitung von nur symptomatisch bekannten Fehlfunktionen, wie es bei Kundenbeanstandung üblicherweise der Fall ist.
Wählt er die Fehlercode basierte Darstellung, also in Fig. 3 den linken Zweig des Ablaufdiagramms , wird ihm im folgenden Schritt 316 die Möglichkeit gegeben, aus den Fehlercodes einen seiner Erfahrung nach geeigneten Fehlercode auszuwählen und dadurch für die weitere Diagnosesitzung einen Fokus zu setzen. Für die weiteren Berechnungen während der Diagnosesitzung können die auszuwertenden Regeln, die in den Durchläufen der Regeltabellenauswertung gemäß den Verfahrensschritten 313 und 314 gefeuert haben, d.h. die entweder den beobachteten Fehlercode oder ein beobachtetes Fehlersymptom enthielten, in einem alternativen weiteren Verfahrensschritt für die weiteren Berechnungen komprimiert werden. Bei der Komprimierung können Syntaxbestandteile und Semantikbestandteile der Diagnoseregeln aus der Wissensbasis entfallen und die Diagnoseregeln zu Zahlentupeln komprimiert werden .
Ebenfalls alternativ können in einem weiteren Verfahrensschritt 318 zu den im Fokus befindlichen Fehlercodes oder Fehlersymptomen die möglicherweise betroffenen Fehlerbilder ermittelt werden und in die weitere Berechnung miteinbezogen werden.
Der Diagnoseablauf fährt fort mit dem Verfahrenschritt 319, in dem die Fehlerwahrscheinlichkeiten für Komponenten und damit die Priorisierung bzw. Gewichtung der als fehlerhaft verdächtigten Komponenten berechnet wird. Liegt die Priorisierung fest, werden die priorisierten Fehlerkandidaten dem Servicetechniker zusammen mit Ihrer Priorisierung angezeigt. Der Servicetechniker überprüft dann nach seiner Wahl die einzelnen Komponenten bzw. Kandidaten. Das Ergebnis seiner Überprüfung entscheidet in einem weiteren Abfrageschritt 321, ob der Diagnoseablauf und damit das Diagnoseprogramm wieder zum Entscheidungsschritt 315 zurück springt oder nicht. Wurde der Fehler gefunden, endet die Diagnosesitzung. Wurde kein Fehler gefunden, wird die Diagnosesitzung fortgesetzt und der Servicetechniker hat die Möglichkeit bei dem nochmaligen Durchlauf einen anderen Fokus zu setzen.
Wählt der Servicetechniker die Funktionsbasierte Darstellung im Entscheidungsschritt 315 aus, wählt er also den rechten Zweig im Ablaufdiagramm nach Fig. 3, so wird ihm in einer alternativen Ausführung des Diagnoseprogramm im nächsten Schritt 322 ein Funktionsbaum zur Anzeige gebracht, in dem die fehlerverdächtigen Funktionen optisch hervorgehoben werden. Durch Auswahl einer verdächtigten Funktion kann der Servicetechniker auch in der funktionsbasierten Darstellung in einem folgenden Verfahrensschritt 323 für den weiteren Diagnoseablauf einen Fokus setzen. Bei der funktionsbasierten Arbeitsweise des Diagnosesystems werden nach dem Setzen des Fokus im folgenden Verfahrensschritt 324 die Regeltabellen des Diagnosesystems ein zweites Mal ausgewertet. Dies ist notwendig, um den Fehlersuchraum für die verdächtigen Komponenten zu ergänzen und möglichst komplett aufzuspannen. In einer Funktion kommen üblicherweise mehrere Komponenten und deren Zusammenwirken zum Einsatz. In den vorhergehenden Schritten wurden die Komponenten aber nur über die Fehlercodes ermittelt. Die Arbeitsweise über die funktionsbasierte Fokussetzung ermöglicht den Fehlersuchraum auch auf diejenigen Komponenten auszudehnen, die über die Funktion identifiziert werden können, und die bisher nicht über einen Fehlercode identifiziert wurden. Die Diagnoseprogramm kann dann mit dem alternativen Verfahrenschritt 317 der Datenkompression oder mit dem Verfahrensschritt 318 der Fehlerbildermittlung fortsetzen.

Claims

Patentansprüche
1. Rechnergestütztes Diagnosesystem (1) für technische Vorrichtungen mit einem ablauffähigen Diagnoseprogramm,
- das mit dem implementierten Diagnoseprogramm Fehlercodes oder Fehlersymptome (FCi,Sympi) der zu analysierenden technischen Vorrichtung erfasst,
- das mit dem Diagnoseprogramm eine Wissensbasis (211) , in der regelbasiertes Diagnosewissen über die zu analysierende, technische Vorrichtung abgelegt ist, nach den erfassten Fehlercodes oder Fehlersymptomen durchsucht und aus den betroffenen Regeln die Komponenten, Funktionen oder Fehlerbilder ermittelt und in einer Fehlerkandidatenmenge zusammenfasst und abspeichert, dadurch gekennzeichnet, dass der weitere Ablauf des Diagnoseprogramms interaktiv durch Setzen eines Fokus beeinflussbar ist, wobei das Setzen des Fokus entweder durch Auswahl mindestens eines Fehlercodes (FCi) oder durch Auswahl mindestens eines Fehlersymptomes (Sympi) erfolgt.
2. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass nach dem Setzen des Fokus die Fehlerkandidatenmenge auf die noch im Fokus befindlichen Elemente zu einer Fokusmenge reduziert wird und die Komponenten der Fokusmenge entsprechend ihrer Fehlerwahrscheinlichkeit gewichtet werden.
3. Diagnosesystem nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Fehlerkandidatenmenge durch mehrfaches Durchsuchen der Wissensbasis nach Fehlercodes zum ersten und nach FehlerSymptomen zum weiteren gebildet wird.
4. Diagnosesystem nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass für das Setzen des Fokus entweder eine Fehlercode basierte Darstellung oder eine Fehlersymptom basierte Darstellung interaktiv wählbar ist.
5. Diagnosesystem nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass sich die Gewichtung der Komponenten in der Fokusmenge durch Verrechnung von relativen Fehlergewichten g(Kj), von bedingten Wahrscheinlichkeiten für die Ursachen-Wirkungszusammenhänge (P (FCi | Kj), P(Sympi|κj), P(FBi|κj)), dividiert durch ein Gesamtgewicht G, ergibt.
6. Diagnosesystem nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das Diagnoseprogramm rekursiv aufgebaut ist und bei jedem Durchlauf des Diagnoseprogramms ein anderer Fokus gesetzt werden kann.
7. Diagnosesystem nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass in der Wissensbasis Fehlerbilder enthalten sind, wobei die Fehlerbilder aus einer Kombination mehrerer Fehlercodes bestehen, die immer gemeinsam auftauchen und in ihrer Gemeinsamkeit charakteristisch für einen bestimmten Fehler sind.
8. Diagnosesystem nach einem der Ansprüche 7, dadurch gekennzeichnet, dass für die Gewichtung der Komponenten in der Fokusmenge, die Fehlerbilder mit herangezogen werden.
9. Diagnosesystem nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass von Fehlercodes über den Umweg über Fehlerursachen (Kandidaten) auf mögliche beeinträchtigte Funktionen oder weitere Symptome geschlossen werden kann.
10. Diagnosesystem nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass damit nach weiteren Symptomen gezielt rückgefragt werden kann bzw. der Servicetechniker sofort weitere Funktionen selbst prüfen kann.
11. Diagnosesystem nach einem der Ansprüche 1 bis 10, dass Kandidaten bei Nichtvorliegen von Fehlercodes oder Symptomen entlastet werden können.
12. Diagnosesystem nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass Mehrfachfehler durch Nacherklären aller Symptome und Fehlercodes nach einer durchgeführten Diagnose erkannt und dann weiterbehandelt werden können.
13. Diagnosesystem nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass z.B. im Fall, dass kein Fehler gefunden wurde ein neuer Fokus auch sehr gezielt dem Servicetechniker angeboten werden kann.
14. Diagnosesystem nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass die Wissensbasis weiterhin um Fehlersetzbedingungen von Fehlercodes und weiteren
PrüfVoraussetzungen angereichert werden kann.
15. Diagnosesystem nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die Wissensbasis um Felderfahrung erweiterbar ist.
16. Diagnosesystem nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass Phantomfehler erkannt werden.
PCT/EP2006/003049 2005-04-06 2006-04-04 Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben WO2006105930A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005015664.9 2005-04-06
DE200510015664 DE102005015664A1 (de) 2005-04-06 2005-04-06 Diagnosesystem zur Bestimmung einer gewichteten Liste möglicherweise fehlerhafter Komponenten aus Fahrzeugdaten und Kundenangaben

Publications (1)

Publication Number Publication Date
WO2006105930A1 true WO2006105930A1 (de) 2006-10-12

Family

ID=36716878

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/003049 WO2006105930A1 (de) 2005-04-06 2006-04-04 Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben

Country Status (2)

Country Link
DE (1) DE102005015664A1 (de)
WO (1) WO2006105930A1 (de)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010091903A1 (de) * 2009-02-16 2010-08-19 Robert Bosch Gmbh Verfahren und vorrichtung zur aufnahme und übertragung von betriebsdaten einer brennkraftmaschine
EP2284631A1 (de) * 2009-07-17 2011-02-16 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Fahrzeugdiagnosesystems, Steuerungsprogramm und Fahrzeugdiagnosesystem
EP2369435A1 (de) * 2010-03-19 2011-09-28 Hamilton Sundstrand Corporation Bayes'scher Ansatz zur Identifizierung von Untermodulausfall
CN102393732A (zh) * 2011-10-24 2012-03-28 力帆实业(集团)股份有限公司 车辆故障诊断方法
US20120116631A1 (en) * 2010-11-09 2012-05-10 Kia Motors Corporation Scheduled vehicle management system and method
WO2013152826A1 (de) * 2012-04-12 2013-10-17 Audi Ag Verfahren zum betreiben eines diagnosesystems und diagnosesystem
EP3569999A1 (de) * 2018-05-14 2019-11-20 CLAAS Selbstfahrende Erntemaschinen GmbH Diagnosegerät zur wartung von zum antreiben von landwirtschaftlichen arbeitsmaschinen vorgesehenen antriebssystemen
EP3741196A1 (de) * 2019-05-14 2020-11-25 CLAAS Selbstfahrende Erntemaschinen GmbH Verfahren zur ermittlung einer fehlerursache bei einer landwirtschaftlichen arbeitsmaschine
US11403895B2 (en) 2016-08-12 2022-08-02 Snap-On Incorporated Method and system for providing diagnostic filter lists
US11887413B2 (en) 2016-08-12 2024-01-30 Snap-On Incorporated Method and system for displaying PIDs based on a PID filter list

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006018831A1 (de) * 2006-04-22 2007-10-25 Daimlerchrysler Ag Kraftfahrzeugdiagnose und Fahrzeugannahme
DE102007010978A1 (de) 2007-03-05 2008-09-11 Volkswagen Ag Verfahren und Vorrichtung zur Unterstützung einer Diagnose eines elektrischen Systems mittels wahrscheinlichkeitsbasierter Fehlerkandidatenermittlung
DE102007015140A1 (de) * 2007-03-29 2008-10-02 Volkswagen Ag Diagnosevorrichtung und Diagnoseverfahren zum Ausführen einer Diagnose eines mechatronischen Systems
DE102007018732A1 (de) * 2007-04-20 2008-10-23 Volkswagen Ag Diagnosesystem und Verfahren zum Erstellen eines Prüfablaufs für eine Diagnose eines mechatronischen Gesamtsystems
DE102007045255B4 (de) 2007-09-21 2021-11-18 Volkswagen Ag Verfahren zur Herstellung eines Diagnosesystems, insbesondere für ein Kraftfahrzeug
DE102008051017A1 (de) 2008-10-13 2010-04-15 Rheinmetall Landsysteme Gmbh Verfahren zur Steigerung der Effizienz von Fahrzeugen bzw. Fahrzeugsystemen mit und ohne Waffensysteme
DE102008051016A1 (de) 2008-10-13 2010-04-15 Rheinmetall Landsysteme Gmbh Verfahren zur Unterstützung bei der Ausbildung an Fahrzeugen bzw. Fahrzeugsystemen mit und ohne Waffensysteme
DE102008058545A1 (de) 2008-10-13 2010-04-15 Rheinmetall Landsysteme Gmbh Verfahren zur Steigerung der Effizienz von Fahrzeugen bzw. Fahrzeugsystemen mit und ohne Waffensysteme

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5442555A (en) * 1992-05-18 1995-08-15 Argonne National Laboratory Combined expert system/neural networks method for process fault diagnosis
DE19523483A1 (de) * 1995-06-28 1997-01-02 Daimler Benz Ag Rechnergestützte Fehlerdiagnoseeinrichtung für ein komplexes technisches System
DE10307365A1 (de) * 2003-02-21 2004-09-09 Volkswagen Ag Vorrichtung und Verfahren zur Fehlerdiagnose bei Fahrzeugen

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE511967C2 (sv) * 1998-09-10 1999-12-20 Mecel Ab Metod och system för diagnosticering av sammansatta distribuerade system, företrädesvis implementerade i fordon
GB2350443A (en) * 1999-05-22 2000-11-29 Luk Getriebe Systeme Gmbh Diagnostic system, particularly for motor vehicles
DE10315344B8 (de) * 2003-04-03 2010-02-11 Audi Ag Verfahren und Vorrichtung zur Erkennung fehlerhafter Komponenten in Fahrzeugen
DE10323384A1 (de) * 2003-05-23 2004-12-16 Daimlerchrysler Ag Diagnosesystem

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5442555A (en) * 1992-05-18 1995-08-15 Argonne National Laboratory Combined expert system/neural networks method for process fault diagnosis
DE19523483A1 (de) * 1995-06-28 1997-01-02 Daimler Benz Ag Rechnergestützte Fehlerdiagnoseeinrichtung für ein komplexes technisches System
DE10307365A1 (de) * 2003-02-21 2004-09-09 Volkswagen Ag Vorrichtung und Verfahren zur Fehlerdiagnose bei Fahrzeugen

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
LAUBER J ET AL: "AUTONOMOUS AGENTS FOR ONLINE DIAGNOSIS OF A SAFETY-CRITICAL SYSTEM BASED ON PROBABILISTIC CAUSAL REASONING", PROCEEDINGS. ISADS. INTERNATIONAL SYMPOSIUM ON AUTONOMOUS DECENTRALIZED SYSTEMS, 1999, pages 213 - 219, XP000949345 *
WALESCHKOWSKI N ET AL: "EIN WISSENSBASIERTES FAHRZEUG-DIAGNOSESYSTEM FUER DEN EINSATZ IN DER KFZ-WERKSTATT", GRUNDLAGEN UND ANWENDUNGEN DER KUENSTLICHEN INTELLIGENZ, September 1993 (1993-09-01), pages 277 - 291, XP002065987 *
WALESCHKOWSKI N ET AL: "WISSENSMODELLIERUNG UND WISSENSERWERB AM BEISPIEL DER FAHRZEUGDIAGNOSE", KUENSTLICHE INTELLIGENZ, BRAUNSCHWEIG, DE, January 1995 (1995-01-01), pages 55 - 61, XP002065986, ISSN: 0940-0699 *

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8612125B2 (en) 2009-02-16 2013-12-17 Robert Bosch Gmbh Method and device for acquiring and transmitting operating data of an internal combustion engine
WO2010091903A1 (de) * 2009-02-16 2010-08-19 Robert Bosch Gmbh Verfahren und vorrichtung zur aufnahme und übertragung von betriebsdaten einer brennkraftmaschine
EP2284631A1 (de) * 2009-07-17 2011-02-16 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Fahrzeugdiagnosesystems, Steuerungsprogramm und Fahrzeugdiagnosesystem
EP2369435A1 (de) * 2010-03-19 2011-09-28 Hamilton Sundstrand Corporation Bayes'scher Ansatz zur Identifizierung von Untermodulausfall
JP2011199867A (ja) * 2010-03-19 2011-10-06 Hamilton Sundstrand Corp サブモジュールの故障を特定するベイズ法
US8458525B2 (en) 2010-03-19 2013-06-04 Hamilton Sundstrand Space Systems International, Inc. Bayesian approach to identifying sub-module failure
US20120116631A1 (en) * 2010-11-09 2012-05-10 Kia Motors Corporation Scheduled vehicle management system and method
CN102393732A (zh) * 2011-10-24 2012-03-28 力帆实业(集团)股份有限公司 车辆故障诊断方法
CN102393732B (zh) * 2011-10-24 2013-05-22 力帆实业(集团)股份有限公司 车辆故障诊断方法
WO2013152826A1 (de) * 2012-04-12 2013-10-17 Audi Ag Verfahren zum betreiben eines diagnosesystems und diagnosesystem
US11403895B2 (en) 2016-08-12 2022-08-02 Snap-On Incorporated Method and system for providing diagnostic filter lists
US11403893B2 (en) * 2016-08-12 2022-08-02 Snap-On Incorporated Method and system for providing diagnostic filter lists
US11694491B2 (en) 2016-08-12 2023-07-04 Snap-On Incorporated Method and system for providing diagnostic filter lists
US11887413B2 (en) 2016-08-12 2024-01-30 Snap-On Incorporated Method and system for displaying PIDs based on a PID filter list
US12106615B2 (en) 2016-08-12 2024-10-01 Snap-On Incorporated Method and system for providing diagnostic filter lists
EP3569999A1 (de) * 2018-05-14 2019-11-20 CLAAS Selbstfahrende Erntemaschinen GmbH Diagnosegerät zur wartung von zum antreiben von landwirtschaftlichen arbeitsmaschinen vorgesehenen antriebssystemen
EP3741196A1 (de) * 2019-05-14 2020-11-25 CLAAS Selbstfahrende Erntemaschinen GmbH Verfahren zur ermittlung einer fehlerursache bei einer landwirtschaftlichen arbeitsmaschine

Also Published As

Publication number Publication date
DE102005015664A1 (de) 2006-10-12

Similar Documents

Publication Publication Date Title
WO2006105930A1 (de) Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben
DE102005027378B3 (de) Dynamische Priorisierung von Prüfschritten in der Werkstattdiagnose
DE10307342B4 (de) Vorrichtung und Verfahren zur modellbasierten On-Board-Diagnose
DE68926130T2 (de) Diagnoseexpertensystem
DE102004024262A1 (de) Wissensbasiertes Diagnosesystem für ein komplexes technisches System mit zwei getrennten Wissensbasen zur Verarbeitung technischer Systemdaten und zur Verarbeitung von Kundenbeanstandungen
DE10244131B4 (de) Verfahren zur Unterstützung einer Identifizierung einer defekten Funktionseinheit in einer technischen Anlage
DE69228803T2 (de) Wartungs-vorrichtung und verfahren ausgelöst durch wissenbasiertemaschine
DE19742446B4 (de) Fehlerdiagnoseverfahren
DE69228986T2 (de) Durch hierarchisch verteilte wissenbasierte maschine ausgelöste wartungs-vorrichtung und -verfahren
DE102012100390A1 (de) Entwickeln eines Fehlermodells aus Servicebeschreibungen
DE102007010978A1 (de) Verfahren und Vorrichtung zur Unterstützung einer Diagnose eines elektrischen Systems mittels wahrscheinlichkeitsbasierter Fehlerkandidatenermittlung
EP2146262A1 (de) Verfahren zum Bestimmen fehlerhafter Komponenten in einem System
DE3751949T2 (de) Verfahren zum Starten eines Untersystems in einem verteilten Verarbeitungssystem
DE102011055456A1 (de) Graph-Matching-System zum Vergleichen und Zusammenführen von Fehlermodellen
DE60002618T2 (de) Verfahren und Analysewerkzeug zur Fehlerortung in einem Rechner
DE102011086352A1 (de) Verfahren und Diagnosesystem zur Unterstützung der geführten Fehlersuche in technischen Systemen
DE102009027267A1 (de) Verfahren und Vorrichtung zur vereinfachten Fehlerverarbeitung an einer Werkzeugmaschine
DE19742448C1 (de) Diagnosemodul zum Erstellen einer Diagnose für elektrisch ansteuerbare Systeme und Diagnoseeinrichtung zum Erstellen einer Gesamtsystemdiagnose
DE102004019151A1 (de) Rechnergestütztes Diagnosesystem auf der Basis von Heuristiken und System-Topologien
WO2003029978A2 (de) Verfahren und system zur bearbeitung von fehlerhypothesen
DE102008004219A1 (de) Verfahren zum Behandeln mindestens eines Fehlers innerhalb eines Systems
DE102012007321A1 (de) Verfahren zum Betreiben eines Diagnosesystems und Diagnosesystem
DE10315344B4 (de) Verfahren und Vorrichtung zur Erkennung fehlerhafter Komponenten in Fahrzeugen
DE102018212801A1 (de) Diagnose komplexer Systeme
DE102012211787A1 (de) Fahrzeugdiagnosevorrichtung zum Ermitteln eines Bedarfs für eine Überprüfung von mindestens einer Komponente eines Kraftfahrzeuges und Fahrzeugdiagnoseverfahren zum Ermitteln eines Bedarfs für eine Überprüfung von mindestens einer Komponente eines Kraftfahrzeuges

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

NENP Non-entry into the national phase

Ref country code: RU

WWW Wipo information: withdrawn in national office

Country of ref document: RU

122 Ep: pct application non-entry in european phase

Ref document number: 06724006

Country of ref document: EP

Kind code of ref document: A1

WWW Wipo information: withdrawn in national office

Ref document number: 6724006

Country of ref document: EP