The invention relates to a computer-aided diagnostic system that with
Help of a diagnostic program from vehicle data and customer information
a weighted list of possibly
created faulty motor vehicle components. The identification
Error candidates take place over
an evaluation of a rule table reflecting the diagnostic knowledge.
By the additional
Evaluation of possibly also affected by the error candidates
Vehicle features will expand the troubleshooting space. The service technician
can by setting a focus within the determined troubleshooting space,
troubleshooting on selected
Restrict error codes or functions. It will be only the
to the selected ones
Error codes or functions possible
Contestants further considered. The error candidates belonging to this focus set
are calculated by calculating several error probabilities for error codes,
Weighted components and affected functions or error symptoms.
Alternatively you can
Compute still known error images, these are coupled error codes,
possibly synonymous symptoms that always occur together, consulted
An example of a system diagnosis is in the German patent application DE 195 23 483 A1
disclosed. 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. In the DE 195 23 483 A1
modeling involves a structural model and an impact model, 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. In 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 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
larger technical systems,
such as. a motor vehicle extremely expensive,
if all possible
Causes of errors to be controlled by the system. Even more difficult
In system diagnostics, ambiguous system states are to be handled when
e.g. a recorded error code can have multiple causes
in the absence of sufficient error environment data or insufficient
the current system status, from the system diagnostics not further
can be processed.
The system diagnostics will then break at this point without diagnostic result
from. Another disadvantage of system diagnostics is their principle
the processing of experience of the service technician. As well
Customer information is limited
to defective functions or to intact functions in the diagnostic process
of the aforementioned type have the further disadvantage that they are very
quickly become very complex and the necessary modeling effort,
Computing effort and calculation effort for larger technical systems exponential
with the number of error possibilities
of the individual components of the overall system increases. Also, for the diagnosis
into a static test step tree
be imaged. In reality
results in systems with several interdependent components
a plethora of possibilities
in which order individual partial tests of individual components
With 5 components there are already theoretically 5 faculty different
Test procedures, the
all through a static test tree
would have to be pictured.
The efficiency of the diagnostic procedures therefore decreases with the number of possible errors
therefore has more efficient options
sought to build a diagnostic system.
One way to improve the diagnostic process is in the European patent specification EP 1 069 487 B1
described. In parallel with the repair progress, knowledge saved by a service technician at crucial points of the test step tree, known as evidence, can be queried and included in the diagnostic system. This eliminates the need to calculate all possible errors and test options. The diagnostic method can become more efficient the more queries are provided at the appropriate point of the diagnostic procedure on the system side. The input of the evident knowledge takes place via a user interface, which is formed by a display and an input menu.
The cost effectiveness of the tests to be performed is desirable for troubleshooting future workshops with diagnostic systems. A quick and efficient test procedure is therefore a good idea worthwhile specification for these future diagnostic systems.
Task according to the invention
It is therefore a diagnostic system to indicate that a meaningful reduction
and that is also capable of providing an economically meaningful exam sequence for troubleshooting
and repair of the to be tested,
Task is solved
with a diagnostic system and a diagnostic method according to claim
1. Further advantageous embodiments
are in the subclaims
and included in the following description.
with an interactive diagnostic program, in which the service technician,
within a troubleshooting space initially opened by the diagnostic program
Defective identified components or functions, a focus
set further, automated troubleshooting by the diagnostic program
can. The setting of the focus can be limited by this
an error code or by restriction to an impaired one
Function or error symptom. After setting the focus becomes
Focus quantity corresponding to the selected
Error candidate selected.
The individual error candidates learn here - by offsetting different
the occurrence of an error code, for the probability of default
a component or function and, if applicable, its presence
of a defect image - one
an advantageous embodiment
the diagnostic system according to the invention
the diagnostic system over
To process error images. Error pictures are combinations here
multiple error codes that are specific to the failure of a particular one
Component or a small amount of components and so a direct
Can supply information on the defective component (s). The error pictures can hereby
a combination of active and inactive error codes
and symptoms are formed. The non-active error codes can be used here
provide particularly valuable information on non-defective components
and so the amount of possible
Restrict error candidates.
a further advantageous embodiment of the invention,
if the review of
Candidates in the focus set revealed that none of the examined
Components was broken, a new focus by the service technician
and thus a new focus set with weighted error candidates
a further advantageous embodiment of the invention can according to
Finding a defective component by clarifying the
Symptoms and DTCs affected by this component
Multiple error can be closed. Also in this case can through
resetting focus on the post-declared symptoms or error codes
the search will be restarted.
a further advantageous embodiment of the invention can
e.g. in case no error was found, a new focus as well
very specifically offered to the service technician. This can be neighborhood relations
of cause quantities, e.g. of error codes,
be exploited. So the search can target other neighbors
Causes quantities are extended. In the case of multiple errors, candidate quantities,
that were not explained by a found bug as a new focus
a further advantageous embodiment of the diagnostic system
can provide the knowledge base of the diagnostic system with field experiences
be extended to the operation of motor vehicles, thus the diagnostic process
to optimize. about
Field experience, e.g. Error rates,
the error weights g (Kj) are adapted. Furthermore, via field data evaluation
further error images FB can be detected and added, which then immediately
can be used in a subsequent diagnostic session.
In a further advantageous embodiment of the diagnostic system, the service technician is given an indication of the presence of a phantom error. For this, a reliability variable -for example P (FC | not Kj) - must be provided for error codes, error images and symptoms, for example in the form of a bit or a further probability. This reliability indicates whether the error code in question (as well as fault pattern, symptom) can also occur without a physical reason for the error. Then, if further error checking does not find an error in the focus, then the reliabilities of the one for the prioritized candidate list are computed Sizes tested. If all the information used in this sense is not reliable or safe, there may be a phantom error.
With the invention mainly the following advantages are achieved:
Due to the interactive design of the diagnostic system, it is possible to incorporate the experience of service technicians during the repair process in the repair and diagnostic process. By setting a focus within a spanned troubleshooting space, the information to be processed is drastically reduced for further diagnostics. As a result, even for complex systems, a further, automated diagnostic procedure is possible, which leads to a reusable result in a workshop environment in acceptable process times.
Weighting of the error candidates within the focus amount is the
Service technician given a prioritization to the hand, with the
giving him an indication, whichever of the possible components is most likely
is defective. This will alert the service technician
which components he should check first,
to a defective component as possible
find. The system automatically offers at least one
Component of the candidate list.
The following is the computer-aided
Diagnostic system explained in more detail with reference to graphical representations.
1 A computerized diagnostic system for a motor vehicle as is well known and established in the art;
2 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;
3 A flow chart for the diagnostic program according to the invention;
In 1 a situation is schematically illustrated, as it is known today in motor vehicle workshops. For the diagnosis of a motor vehicle is a computer-aided diagnostic tester 1 via a standardized diagnostic interface 2 to the communication network 3 for the control units 4 connected in the motor vehicle. Known diagnostic testers are, for example, the DAS system from DaimlerChrysler or the BMW-DIS system. The control units installed in the motor vehicle 4 For example, they are in communication with each other via a data bus. A common data bus in motor vehicles is the so-called CAN bus (for Controller Area Network). Each of the installed control units in the motor vehicle has the ability to self-diagnose in addition to the communication interfaces. 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 fault memory, are written with the aid of the diagnostic routine in the control units. In the schematic representation of 1 For example, these reserved, non-volatile memory areas are referred to as FS (for error memory). For the communication and for the data exchange between a diagnostic tester and the control units installed in the motor vehicle, a standard has been established, known under the name Keyword Protocol 2000, whose specification and standardization can be found in ISO standard 14 230-3. With the control commands and data formats agreed upon in the Keyword Protocol 2000, it is possible to use the diagnostic interface to read out the codified contents of the fault memories of the individual control devices with the aid of the diagnostic tester and to transfer them to the computing system of the diagnostic tester. The standard for the keyword protocol 2000 comprises two different application options. On the one hand, the standard stipulates that the communication between the diagnostic tester and ECUs is via a gateway 5 , for example, the motor vehicle CAN bus to the diagnostic interface 2 binds, takes place or that, as was customary in the past, the fault memory of the control units via the so-called K and L lines and the standardized diagnostic interface 2 can be read out and stored directly in the diagnostic tester. In the schematic representation of 1 is the more modern form of access via a CAN bus and thus represented by a gateway. For 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. In the diagnostic tester, the transmitted contents of the control unit memory become error codes and status data in particular the control units processed with an implemented diagnostic program in a diagnostic session. The diagnostic program also includes the option of manually entering additional information that is important for a diagnosis via a computer workstation as a human-machine interface.
2 shows as a block diagram the most important program modules and realized with these program modules functions of 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 input from a computer workstation 200 , which is typically equipped with a screen and a computer keyboard, each to the computer system 201 connected to the diagnostic system. About another 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. It can be read out the error memory of the control units, 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 technical realization was related to 1 discussed.
However, the processing of the system data and the course of the diagnostic program deviate significantly in the invention from the known prior art. The most important differences here are the interactive course of the diagnostic program and the associated possibility of forming targeted diagnostic focuses, in which one or more focal points, referred to hereinafter as foci, can be set for debugging, thus improving both the diagnostic quality and the duration of the diagnosis can. The program implementation will be described in more detail below:
The diagnostic program implemented on the computer system is characterized among other things by a modular structure. As a result, among other things, the programming and the configuration of the diagnostic system are structured. With 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 for each component installed in the motor vehicle, read and processed. Further processing involves checking in a knowledge base 211 saved rule tables. 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.
Component identifiers Ki give an indication of which component or component
also which function of the technical system for the observed error code
the observed error symptom can be the cause. Result
This first scouring of the knowledge base is a first set
the over due to the identification
the error codes FCi were determined.
In a further processing step or program module 213 the troubleshooting space formed by the first candidate set is further developed. In a second pass through the knowledge base, the possible sources of error are now extended by the relevant functions that may be involved in the motor vehicle. For this purpose, 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.
Arrived at this point, now begins the possibility of interaction in the further course of Di agnoseprogramms. First, on the screen workstation 200 a query 215 performed and displayed whether the already determined error codes or the determined possibly affected functions should be displayed for further processing. About the difference will be discussed below in connection with the description 3 discussed in more detail. In both cases, in a further process step 216 The service technician had 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.
For the components Ki which are still suspect within the focus, the individual error candidates are identified in a further program module or method step 217 subjected to a weighting.
For the weighting
the probabilities of error codes FCi, the probability
Occurrence of sympi and possibly the probability for the existence
be calculated from defect images. This requires probabilities
which indicate with what security a defective component
or a candidate Ki an error code (P (FCi|Kj)), a malfunction
or an error image (P (FBi|Kj)),
becomes the relative error weighting g (Kj) of a component itself
This information will be for
the calculation of the prioritized or weighted candidate list
The conditional probabilities are easy to estimate. Most of time
they are set to "l". Uncertain symptoms
or error codes can
but sometimes accept values less than 1. The error weights g (Kj)
from experience, e.g. be chosen between one and a hundred
and represent a relative failure characteristic. In a below explained
can also over
these error weights g (Kj) take into account the current field occurrence
be by putting these weights over
Offsetting of error frequencies
All the probabilities and error weights are stored in the database when the diagnostic system is defined 218 stored. 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 Wahrscheoinlichkeiten and the error weights. Expediently, the data is model-specific. However, cross-product databases can also be created and used. In the case of cross-database databases, however, the possibility of a series-specific selection, eg in the form of an upstream master table, must then be maintained.
From the data explained above, the individual variables are calculated as follows:
become three calculated sizes
to prepare the candidate prioritization, below. G
is a normalization size and will
in a preparation step or by means of e.g. as the sum of all
Weights g (KJ) determined.
After the probabilities of the error codes P (FCi), the error images P (FBi) and the malfunctions P (Sympi) have been calculated and the focus quantity of the error candidates is determined, the calculation of a prioritized or weighted candidate list can be performed 219 and finally on the screen of the workstation 200 be issued.
The a posteriori error probability or priority Prio (Ki) of a component Ki results from the following product:
applies: P (FCi|K)
= P (FCi) if the error code FCi is independent of a component K.
and analogously P (Sympk|Ki)
= P (Sympk) and P (FBl|Ki)
= P (FBl) at independence
from the respective component.
is still not standardized and can alternatively be normalized by
divided by the sum of all candidate priorities.
The following conditions apply to the individual calculations:
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.
must be checked after each calculation
be that the prioritization value of a candidate within the
Focus amount does not become 0. Should this nevertheless occur, then for the concerned
Prioritization value for
the data format double smallest, possible, positive numerical value
Calculation of the weighted candidate list can be done within a
Diagnostic session are repeated several times. This is e.g. necessary,
if the review of
Candidates from the first focus set by the service technician
led to no positive findings
Has. In this case, the service technician must have the opportunity
have, by choosing a different focus, a different candidate list
to create. something similar
applies to multiple errors.
After the before described again with reference to the flowchart of 3 the diagnostic program implemented in the diagnostic system. At the beginning of a diagnostic session in the presence of at least one error code, a malfunction or an error symptom Symp is first a short test 310 started. With this short test, the self-diagnostic routines of the control units installed in the motor vehicle are started and then in a subsequent method step 311 , read out the error memory of the control units and generates a list of all active error codes possibly with the associated error environment data. Subsequently, in a further process step 312 by means of a master table which selects control tables valid for the motor vehicle to be examined for the diagnosis. The identification of the vehicle and the identification of the valid control tables can take place here, for example, via the vehicle identification number. In two further steps of the rule table evaluation 313 and the identification of relevant functions 314 For the reported error codes and the reported malfunctions, the possibly affected components, further functions and error images are determined.
In 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 fault 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.
Does he choose the error code based representation, ie in 3 the left branch of the flowchart, it becomes in the following step 316 given the opportunity to select from the error codes one of his experience suitable error code and thereby set a focus for the further diagnostic session. For the further calculations during the diagnostic session, the rules to be evaluated in the runs of the rule table evaluation according to the method steps 313 and 314 have fired, ie either the observed error code or an observed error symptom, are compressed in an alternative further process step for further calculations. During compression, syntax components and semantic components of the diagnostic rules from the knowledge base can be omitted and the diagnostic rules compressed into number tuples.
Also alternatively, in a further process step 318 for the fault codes or error symptoms in focus, the possibly affected faulty images are determined and included in the further calculation.
The diagnostic procedure continues with the procedure step 319 in which the error probabilities for components and thus the prioritization or weighting of the components suspected as being faulty 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 his review decides in another query step 321 Whether the diagnostic procedure and thus the diagnostic program return to the decision step 315 jump back 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.
The service technician selects the function-based representation in the decision step 315 So he chooses the right branch in the flowchart 3 , it will be in an alternative version of the diagnostic program in the next step 322 a function tree displayed, in which the suspect functions are highlighted. By selecting a suspected function, the service technician can also use the function-based representation in a subsequent method step 323 set a focus for the further diagnostic procedure. In the function-based operation of the diagnostic system are after setting the focus in the following process step 324 the control tables of the diagnostic system evaluated a second time. 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. In the previous steps, however, 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 can then use the alternative method step 317 the data compression or with the method step 318 continue the error image determination.