WO2005111752A1

WO2005111752A1 - Knowledge-based diagnostic system for a complex technical system, comprising two separate knowledge bases for processing technical system data and customer complaints

Info

Publication number: WO2005111752A1
Application number: PCT/EP2005/004816
Authority: WO
Inventors: Martin Konieczny
Original assignee: Daimlerchrysler Ag
Priority date: 2004-05-15
Filing date: 2005-05-04
Publication date: 2005-11-24
Also published as: US20070226540A1; DE102004024262A1; EP1751637A1

Abstract

The inventive diagnostic system supports the location of defects that occur intermittently by logging said defects in a temporary onboard diagnosis or a temporary remote diagnosis with subsequent evaluation at the garage. The basic advantage of said method is that the customer retains his or her vehicle during the defect location process.

Description

DaimlerChrysler AG

Knowledge-based diagnostic system for a complex technical system with two separate knowledge bases for processing technical system data and for processing customer complaints

The invention relates to a diagnostic system from the category of model-based system diagnostics. In these computer-aided diagnostic systems, the technical system to be analyzed is mapped with a computer-processable model and by means of sensors and

Error detection algorithms monitored for errors that occur. The errors are codified and evaluated by means of a knowledge base, which contains the diagnostic knowledge relevant to computer-aided diagnosis, and a diagnosis system. The evaluation here is essentially based on the determined error code and the diagnostic system determines the amount of error candidates assigned to the error code from the knowledge base. In a further step, the number of fault candidates by taking so-called error environment data, ie during the occurrence of the error present additional system data, and their consideration reduced by ^{'error-specific} exclusion criteria of the diagnostic system to a minimum. Alternatively, the remaining error candidates can still be evaluated and weighted by the diagnostic system. Such model-based diagnostic systems are known in various forms from the prior art.

DE 195 23 483 AI discloses a model-based, computer-aided diagnosis system in accordance with the preamble of the independent claim, in which the model formation comprises a structural model and an action model, which is often also referred to as a behavior model. The structural model depicts the physical relationships between the individual components of the technical system and the behavior model depicts the functions of the individual components of the technical system. The diagnostic knowledge relevant to the diagnosis is stored in a knowledge base. The diagnostic system can be used to identify errors and, by using the knowledge base, computer-aided troubleshooting. The diagnostic system itself has only and only access to error environment data from the technical system and to a knowledge base that is based exclusively on the error-specific evaluation of the technical system data. Customer complaints or symptomatic error descriptions can only be taken into account by menu control carried out by an experienced service technician, if the technical system data and the error environment data make it impossible for the diagnostic system to provide a clear diagnosis or no diagnosis at all.

Another possibility of model formation, as it is understood and is suitable under the term model-based system diagnosis in the sense of this invention, is disclosed in detail in EP 1 069 487 B1, for example. Here the technical system to be diagnosed for computer-aided diagnosis with a probability network, mapped and modeled in a so-called Bayes network. Modeling with probability networks has the advantage that modeling can take place at the functional level of the individual components of the system. The individual components themselves do not need to be modeled down to a physical structural model. However, one buys this advantage with the problem of finding the right apriori probabilities of the Bayesian network. In accordance with an error message that has been found, a probability distribution that maps the system states within the probability network is calculated by means of a knowledge base, and an error statement is made from this with a diagnostic system, and a remedial measure that is suitable for this error message is proposed. In order to improve the diagnostic result, question nodes are integrated in the probability network, which make it possible to ask simple yes / no questions to a user of the diagnostic system via a human-machine interface during the diagnostic process. By answering the questions, evident knowledge is queried at crucial network nodes in the diagnostic process and introduced into the diagnostic process, so that the diagnostic result is significantly improved with the help of this evident knowledge. However, only evident knowledge can be entered, the query of which was provided by the system designer and implemented in the form of a questionnaire in the modeling. After incorporating the queried evidentiary knowledge, a probability distribution within the network is calculated, taking into account and taking into account a knowledge base that contains the functional technical relationships of the individual components of the technical system, and the most likely cause of the error is deduced therefrom. The modeling effort for model-based system diagnostics is high. In particular, the quality of the diagnostic result depends crucially on the modeling. One is therefore looking for alternatives to model-based system diagnostics. Such an alternative is a symptom-based approach, as described for example in DE 102 35 416 AI. In the symptom-based approach, the technical system is not modeled. Instead, simple, for example, acoustic symptoms are recorded and compared with already known patterns. If a known pattern is found for a symptom that arises, the diagnosis process has largely ended. One then examines the amount of error candidates assigned to the pattern found until one has found the exact error.

A problem with all of the computer-aided diagnostic systems described above is that they are only able to process predefined and thus known error messages and complaints. This also makes the complex modeling necessary, since attempts must always be made to identify and map all possible complications when designing the diagnostic system. And even then, it is not possible to process customer complaints, which are naturally only described symptomatically without detailed technical knowledge, with computer support and only use them for the diagnostic process.

This has two major disadvantages. On the one hand, there is a risk that the error space in which the set of error candidates is to be found is not spanned far enough. This risk is always particularly great if an error reported by a customer occurs intermittently, i.e. only occasionally and not permanently. Such mistakes cannot be found by known computer-aided diagnosis systems, since they are dependent on the presence of an error code and span the error space around the error code.

The second disadvantage is the loss of information that occurs when the customer experience is not used or is insufficiently considered. This customer experience with an occurring error symptom can be used to further limit the number of identified error candidates if the error space is correctly spanned and the number of error candidates is correctly identified. For example, for a "set of errors" seat control defective "with a customer complaint" the seat can only be moved upwards "it can be excluded with computer support that the actuator of the seat mechanism is defective.

The task according to the invention is therefore to extend existing model-based diagnostic systems to the extent that symptoms reported by customers are integrated into the computer-aided diagnosis process and are processed computer-aided during the diagnosis process.

The problem is solved with a diagnostic system with the features of the independent claim. Advantageous embodiments of the invention are disclosed in the subclaims and in the description of the exemplary embodiments.

The solution is mainly achieved by supplementing a known model-based diagnostic system with a second symptom-based branch and a second knowledge base, which is filled with customer complaints using a symptom tree. The symptom tree is necessary to convert the wording of the original customer complaint into machine-processable statements that can be interpreted by the diagnostic system using a computer. Thus, with the symptom tree for a symptom contained in the customer complaint in the original wording, further information in the symptom environment of this symptom is queried. Of particular interest here is information about which functions are intact in the symptom environment in the event of a reported customer complaint. As this allows the diagnostic result to be improved quickly and easily during a final evaluation. This final evaluation is designed as an error candidate calculation. First, a first set of errors is determined using the purely model-based branch of the diagnostic system. Then a second set of errors is calculated using the symptom-based branch of the diagnostic system. The second

The number of error candidates can include information about error candidates reported by the customer as intact. In the end, the two sets of error candidates are offset against one another by excluding the error candidates that are not diagnosed as defective in both sets of error candidates at the same time.

In one embodiment, the

Error candidate accounting by excluding the error candidates reported as intact in one of the two error candidate quantities.

In an alternative embodiment, the error candidate is calculated by intersection formation. Only those error candidates are considered that are present in both error candidate sets at the same time. In an alternative embodiment, which is suitable for model-based diagnostic systems based on Bayesian networks, the prioritization of the individual error candidates takes place in both error candidate sets. When the error candidate is calculated, those error candidates are determined which have the highest total priority from the two error candidate sets.

The main advantages achieved with the invention are improved diagnosis. With the system it is possible to process customer complaints in the original sound. The processing of the customer complaint can be carried out in cooperation with the customer when the symptom tree is processed, or only subsequently by a service technician in the service workshop by processing the symptom tree.

Another advantage of the invention is that the symptom-based branch of the diagnostic system can also be used to deal with errors that occur intermittently. It is also an advantage that the symptom-based branch of the diagnostic system is not bound to any error codes that are necessary in purely model-based diagnostic systems and that must be supplied by control units.

In a further advantageous embodiment of the diagnostic system, after the fault candidates have been determined, the test step tree then required in the workshop is assembled and formed by the diagnostic system from predefined and stored test step primitives. This enables a dynamically clamping of a flat and wide as possible with the progress of diagnosis Test step tree to support the service technician in the service workshop.

An embodiment of a diagnostic system according to the invention is explained in more detail below with reference to figures.

Show:

1 is a data flow diagram of the diagnostic system,

2 shows a system architecture,

3 the symptom processing,

4 the processing of vehicle-internal data,

5 shows the generation of error candidates,

6 the processing of further input data,

7 the error candidate calculation,

8 the setup of the test step tree,

9 the error candidate quantities in the error space,

10 shows an overall sequence of the diagnostic method,

11 the spanning of the test step tree from test step primitives.

The following description reveals the modular system structure and the functionalities of the individual modules. The exact interaction of the individual components in troubleshooting is also shown.

system architecture

To meet the requirements for the best possible flexibility, expandability, maintainability and use of current technologies To be able to perform fault localization, the diagnostic system is initially divided into seven modules:

• Processing of vehicle-internal data (as an extension of today's system diagnosis). The diagnostic system automatically evaluates vehicle-internal information to generate error candidates. Vehicle data can burden and relieve error candidates.

• Symptom onset. The transfer of the customer complaint, i.e. the original description of the problem on the part of the customer, into a technical description of the problem in a standardized form is referred to as symptom entry. If the customer calls intact functionalities, these must also be standardized in a suitable form.

• Symptom processing. Based on the information from the DMS (Dealer Management System) and the symptom onset, error candidates are generated. At this point, customer statements regarding intact functions can also be processed.

• Error candidate allocation. The error candidates generated from the symptom processing, the processing of vehicle-internal data and possibly from further previous information processing are to be offset against each other. The allocation determines a number of error candidates, including a weighting of the individual elements.

• Dynamic clamping of test step trees. The identified error candidates must be checked systematically. For this purpose, a test step tree is dynamically spanned according to the error candidate. The systematic review is based on the costs and information content of individual test step primitives. The degree of user guidance ultimately decides whether the tree should be opened once tension, or whether it may need to be corrected after each test.

• Processing the vehicle history. For every visit to the workshop of the vehicle there is a report with the replaced components etc. This data can simplify troubleshooting since the probability of a faulty component as the cause decreases with each replacement of this component.

• TIPS / NEWS. Before systematic error localization with the help of the guided troubleshooting, a request for existing remedies is started to the TIPS / NEWS system. The database is based on known and clearly identifiable errors. The request is based on the currently available input data.

1 shows the data flow of the entire information processing on the basis of the first five modules from the above list. The processing of the vehicle history is omitted here for the sake of clarity. TIPS and NEWS are dealt with separately below.

The information from the vehicle and the customer complaint are available as input data. After the processing shown, there is a test tree that has to be processed.

2 shows the data flow on the basis of the quantities to be processed. At the same time, the system architecture of fault localization can be seen.

The system architecture is characterized by a modular structure with defined interfaces. The individual components are interchangeable and can be further developed. Due to the possibility of exchange, the individual processing steps can be adapted to the state of the art. In contrast to FIG. 1, the processing of the vehicle history is integrated in the display. It is a branch parallel to the processing of symptoms and the processing of in-vehicle data. Likewise, further data inputs are possible, all of which map one type of information to error candidates.

Essentially, FIG. 2 simultaneously shows the sequence that can be read from top to bottom. The processing of the vehicle's internal data, the symptom and the vehicle history can work automatically and in parallel. The results of all three processing steps are error candidate quantities that have to be offset. In the last step, the targeted error candidate check and thus the systematic error localization takes place.

The individual components of the diagnostic system: Each module is determined by its external behavior. The input and output data are clearly defined. Various techniques can be used for data processing within the individual modules.

Symptom entry module (and customer information)

The symptom entry serves to standardize the customer complaint in the form of the original tone for further processing by machine. A clear symptom tree should be used to integrate the terms. This refines the terms (symptoms) according to a functional approach. Alternatively, a special MMI symptom tree (human-machine interface), which maps the terms from the original tone of the customer complaint to the technical terms of the workshop staff in the form of a thesaurus or a lexicon, can be used for the interface to the customer. The MMI symptom tree is characterized by the fact that customer statements are classified in several ways can. For example, a distance radar is part of both the engine and driving comfort or the controls in the interior. Since a clear symptom is required for further processing, there is an assignment of the entries from the MMI symptom tree to the clear (actual) symptom tree. Table 0-1 shows the main characteristics of the onset of symptoms.

With manual standardization, the service technician navigates through the symptom tree. The service technician can stop standardization at any stage. If the service technician stops at a relatively high level, the imprecise symptom provides a relatively large troubleshooting area. For this reason, the repair department strives to provide the customer with the most detailed information possible.

In principle, the symptoms can be started immediately when the vehicle is accepted. Corresponding functionalities of the diagnostic system must be provided for this. If there is a connection to the vehicle before the symptom entry or at the time of the symptom entry, the symptoms consistent with the vehicle data can be highlighted. This mechanism is considered in more detail in symptom processing below.

An important extension of the symptom entry is the equivalent processing by the customer of an indication of the intact functioning units. This information must also be standardized. In addition, when making a complaint, the customer should also state whether the complaint is permanent or sporadic. Depending on this information, different error candidates are charged, in particular, however, the nature of the load changes and thus the further procedure for troubleshooting. Detailed information on the localization of sporadic errors is given below in the description. Table 0-1: Characteristics of the onset of symptoms

The manual assignment between the MMI Sysmptom tree and the Sysmptom tree, which is ultimately used by the diagnostic system for troubleshooting, is deliberately specified as the processing method when the symptoms start. In principle, there are many mechanisms that automatically classify and assign semantic terms. However, automatic procedures usually bring a further vagueness to troubleshooting because they work with similarity criteria. It is therefore recommended to manually standardize the customer complaint at this point, especially if the customer is present.

Of course, the customer can also name several symptoms that specify the search area or refer to multiple errors. In addition, the optional specification of perfectly functioning systems is desired but not absolutely necessary. The latter ultimately lead to an error candidate restriction.

In cooperation with the symptom processing, a dialog can be realized that guides the input of the customer complaint. If, for example, the symptom "seat adjustment front / rear" is entered, the symptom processing determines all suitable error candidates. On the basis of the error candidates, all symptoms can be determined contain at least one of these error candidates. The customer is asked about these symptoms and can comment on them by indicating whether the symptom is permanent, sporadic or not. This limits the search space. If the customer gives no or only partial information, the troubleshooting worsens. U. accordingly, since the search space is larger.

symptom processing

In symptom processing, the standardized symptom is mapped to error candidates. In the same way, customer details are processed that relate to perfectly functioning parts. With the help of the latter information, error candidates are relieved. Consequently, only the processing of symptoms is described, but the presentation relates in the same way to the customer information of the intact functions.

In order to evaluate the correct knowledge bases, the vehicle data, in particular the vehicle identification number FIN, must also be specified, or information from the current troubleshooting must be read from the context and taken into account. Since the symptom is based on the customer complaint, it is an unsharp or rather uncertain knowledge.

Different methods can be used to process the symptom. Raum, F .; Schreier, N .; Spöttl, G.: “The future of computer-aided vehicle diagnostics. Computer-assisted manual work or qualified specialist work. ", Published by Bertelsmann Verlag, Bielefeld 2002, contains a comparison of different technologies. Among other things, case-based reasoning (CBR) is suitable, since this involves blurred processing. The CBR tries to use defined methods Similarities to derive the current case from an already known case. Another possibility and very vivid method is rule-oriented processing. In the rules, the relationships between a symptom and the possible error candidates can be stored in a simple manner. However, there are limits in the long run, since only a direct connection between the two types of information symptom and error candidate is possible. In complex systems, the relationship cannot be directly related, since there is actually a complex interplay of many functionalities.

A detour via function models is therefore recommended for complex technical systems. A suitable technique at this point is the use of Bayes' networks, which allow the relationships between symptoms and error candidates to be modeled over any network.

Table 0-2 summarizes the processing step for symptom processing.

Table 0-2: Characteristics of symptom processing

An important property of the planned symptom processing is the possibility of a candidate allocation based on multiple entries. Many errors affect different customer complaints at the same time. An example of this is a blown fuse. If such an error occurs, several functionalities are disrupted at the same time. If the customer knows some of them, they can significantly speed up troubleshooting.

The symptom tree (MMI symptom tree or similar) is also required for symptom processing. This has the advantage that a symptom cannot always be classified down to the smallest level of differentiation. If the symptom is only known at a higher (less precise) classification level, all the underlying symptoms are used to map the error candidates.

With the help of symptom processing and symptom entry, a dialog can be implemented to minimize troubleshooting times.

Processing of in-vehicle information

When processing vehicle-internal data, error candidates are calculated on the basis of the stored error codes and their environmental data, the vehicle configuration and the available actual values of the vehicle. If the symptom is known, the relevant control units are evaluated. For this purpose, if possible, a connection between the standardized symptom and the affected control units must be provided. With the help of such information, it would not be necessary to consider all of the vehicle's internal data, but to focus on the relevant part. The focus on the relevant control units creates a significant acceleration in the communication application and thus in the entire process. Table 0-3 summarizes the processing of vehicle-internal information.

Table 0-3: Characteristics of the processing of vehicle-internal data

4 shows the processing of the vehicle-internal data graphically. The processing of vehicle-internal data is currently taking place onboard. It includes the diagnosis of CAN-B components as well as CAN line faults. For the BR 221, an expansion of the diagnosis to all CAN and must components is planned. From BR 204, processing takes place exclusively offboard. In the BR171, the CAN-C area is to be covered offboard, while the CAN-B area is processed onboard. The modular concept allows the planned development process.

Today's onboard diagnostics (system diagnostics) work in a rule-oriented manner and must be severely limited in their scope and depth of diagnostics due to the resources available. This does not allow you to reach your full potential. On the other hand, there is a situation-related burden and relief. By relocating the processing of vehicle-internal data, U. important in- formations lost, which has to be compensated. On the other hand, there is much more performance available so that this processing section can be used to the best possible extent.

The automatic processing of vehicle-internal information can also be implemented off-board if appropriate interfaces are provided in and to the vehicle. Different methods are suitable for automatic processing, depending on the problem. For example, rule-based or model-based processing can be used. Structural model analyzes on physical models allow problem decomposition and the investigation of the diagnosability.

Graph-theoretical approaches enable a topology evaluation to determine the components or function groups involved in the error. The available resources and the degree of knowledge preprocessing determine the use of the respective technology. Based on the defined interface information, the methods are interchangeable and a multimodal diagnostic procedure can be configured.

Case based reasoning methods can also be used. This aspect is discussed in more detail in FIG. 5 with a graphic representation. The TIPS and NEWS systems are standalone reasoning (CBR) software components that are integrated into the fault location. The data set available at the beginning, consisting of the vehicle's internal information as well as the symptom and vehicle data, is transferred to the TIPS and NEWS systems. The systems search their own knowledge bases for cases that match the input data. If such a case exists, the system signals the presence of a remedy. In the simplest case, the remedy can be output directly, but this is not recommended because the systematic troubleshooting is no longer possible. It is much more important to use the additional information for targeted and systematic troubleshooting.

Table 0-4: Characteristics of the database queries in TIPS and NEWS during error localization

In principle, the uniqueness of the search results is not guaranteed, so that the database query may May provide more than one remedy. Since error remedies are in principle repaired or exchanged with each remedy, the remedies can be mapped onto error candidates with certainty, so that in the event of an ambiguous solution they result in a lot of error candidates. With the help of the case-specific voltage test tree, the number of error candidates can be systematically limited in the further course of troubleshooting. At this point it is necessary to integrate the results of TIPS or NEWS into the diagnostic system described here. The corresponding interfaces between the managed fault location and the TIPS and NEWS systems must be specified. Table 0-4 describes the most important characteristics of the entire processing step in error localization. For a complete integration of TIPS, the system must report the underlying error candidates if a remedy is found. The method designed here can then treat the error candidates appropriately weighted in the same way as all other error candidates. 10 illustrates the complete integration of TIPS / NEWS into the diagnostic system.

The NEWS system also contains repair instructions, damage codes for billing and spare part numbers. The relevant information is referenced after the error has been successfully localized.

Processing the vehicle history and further input data. FIG. 6 illustrates the basic expandability of the diagnostic system by further modules. Of particular interest is the integration of databases that contain information about the vehicle history and thus information about repairs and maintenance that have already been carried out. The vehicle history contains information on repairs that have already been carried out and can only be used to a limited extent for fault location. Among others complaints and the exchanged components emerge from the vehicle history. If a component was replaced a short time ago, the likelihood is relatively low that the component that has already been replaced will be the cause of the same customer complaint. Rather, the replaced component will be a consequential error or an in order removal. This means that the suspected component may be defective again, but it is not the cause of the customer complaint. Table 0-5: Characteristics of vehicle history processing

The evaluation of the vehicle history is mainly limited to a database query. Based on the vehicle data used to identify the vehicle, the query delivers the components that have already been replaced. These can U. serve to relieve error candidates in the current troubleshooting.

An integration of the processing of the vehicle history should be seen at this point as an option for the diagnostic system. The same applies to other processes not specified here, which e.g. Map the wear status or the date of receipt of components in the vehicle for fault candidates. 6 thus illustrates the generally applicable expandability of the diagnostic system by further modules.

Candidate allocation Candidate allocation reduces the number of error candidates to be considered. At the same time, the error candidates to be considered are prioritized. This means that the troubleshooting room is narrowed down and evaluated. 7 illustrates the processing process of the candida billing based on the most important error quantities involved.

Starting point of the clearing form the above the vehicle-internal data and on the customer complaint based determined amounts of the load (K generating _driving, Ksymptom, (KTIPS, K _NEWS)) and discharge candidates {-ιK _vehicle,

• In the first step, a parameterizable algorithm is implemented for candidate allocation, which builds on existing diagnostic algorithms from the prior art on the basis of component recognition, fault type recognition by means of error codes. These existing diagnostic systems and their algorithms are extended by the following aspects:

• Exposure candidates that match both in the component and in the type of error and result from both the symptom and the processing of vehicle-internal data are the most likely cause of the error.

• Within the intersection (K _vehicle n Ksy _mptom ), which takes into account the component and the type of error, a weighting takes place according to the probabilities existing from the previous processing steps.

• A candidate of the relief amount -> K _Fa h _rz eg or -ιK _Sy mpto _m relieves a corresponding exposure candidate if the component and type of error match.

• In the case of different types of errors in a component, complete relief of an error candidate can only take place if there are appropriate relief candidates for the component in all possible error types. A suitable knowledge base must be provided.

• If a component is loaded with different types of errors on the part of the symptom and on the part of the Processing vehicle-internal data before, the burden of the error candidate from processing vehicle-internal data is to be weighted higher.

As a further option, the algorithm can be improved by methods for multidimensional optimization problems. Table 0-6 characterizes the candidate allocation, whereby in addition to the quantities already mentioned, the error candidates from the TIPS and / or NEWS remedy systems are also taken into account. If there are remedies for the given input data in TIPS and / or NEWS, they must be provided with the suspected error candidates. Candidate allocation takes over the integration of the data.

Table 0-6: Characteristics of candidate allocation

Case-specific generation of the test tree

If the candidate allocation has come to a result and has determined an amount of error candidates, the diagnostic system can optionally further restrict the amount of error candidates by recommending a test step tree to the service technician. With the help of the test steps, the number of error candidates should be considered taking into account the test costs. can be narrowed down atically. The aim is to narrow it down as quickly as possible. In order to achieve a manageable modeling of the tests, the test steps are implemented as primitives. A primitive is, for example, a check instruction for the functional check of a component installed in the motor vehicle or in the case of general malfunctions that affect several components. The algorithm of the diagnostic system takes over the selection and evaluation of the test step primitives and spans a test step tree that is in the Workshop is processed. The setup is based on

• the amount (number) of suspected error candidates, • the error probabilities of individual error candidates, • the cost of individual tests, • the fastest possible limitation of the error.

Table 0-7 shows the characteristics of the test step tree generation. 8 and 10 illustrate the data flow and the selection of the test step primitives for setting up the test step tree.

Table 0-7: Characteristics of the dynamic test steps

The result is an implicit form of a test step tree that shows the error as a function of the previously determined number of error candidates, taking into account the standing costs localized. To implement the troubleshooting strategy, the structure of the test step primitives must contain the elements according to Table 0-8.

Table 0-8: Data structure of the test step primitives

In addition, dependencies of the tests must be taken into account in order to be able to adhere to the necessary sequences. In the future, the tests should be separated into previous work, test and subsequent work. The preceding or following work includes, for example, the exposure of a component to be tested. The The algorithm is then able to take these activities into account. This means, for example, that after a component has been removed, all tests that require this removal can be performed.

In addition to the test step primitives, more complex test structures with multiple outputs and different statements can also be used. They can be used to map complex, coherent processes. Depending on the context, the structures, such as the primitives, are used by the algorithm, so that there is an optimal sequence for the diagnostic process in the workshop.

fault location

The diagnostic system disclosed here pursues the goal of guided troubleshooting. The guidance takes place in a manner known per se with a screen menu. Certainly there will also be the possibility of a short test and thus full data access. In such a case, the service technician has the opportunity to work past the tour. This results in enormous costs today because the service technician has any freedom in troubleshooting with these options and thus takes his own systematic in troubleshooting. In addition, there are very often suspicious repairs. On the other hand, there will always be a short test or access to diagnostic data via a product structure, since access for a system check or a targeted expansion of the diagnostic system must be accessible.

For these reasons, the order should decide on the degree of leadership when accepting the customer. If a replacement of a previously determined component is required, diagnostic data can be reached via direct but direct access. However, if the error is unknown and the order has a fault search, the access described must be prohibited and only the guided fault search must be accessible.

Overall process in the search for permanently existing errors

Permanently existing errors can be localized by systematically evaluating the available information with the help of further measurements. At this point, the entire troubleshooting process should be explained using the amount of data processed in the background.

Guided troubleshooting

FIG. 9 illustrates the relationship between the individual set of error candidates, specifying the diagnostic module from which they were generated and their relationship to the entire troubleshooting area.

The vehicle data and customer complaints are recorded during vehicle acceptance. The customer complaint is therefore available as the original wording and must be mapped to standardized symptoms. For the best possible limitation of the troubleshooting area, several symptoms can be specified, since many errors affect different symptoms at the same time. Differentiation into a permanent or sporadic symptom helps to specify the type of error. In principle, it is also conceivable to specify perfectly functioning system parts at this point, which would lead to much faster troubleshooting by excluding error candidates. Symptoms can be entered in the vehicle reception (dealer management system). However, since there are twelve different acceptance systems worldwide, the symptom entry in the workshop may have to be carried out manually by the service technician.

After the symptom entry, all available information is processed. The evaluation takes place in the background on the diagnostic computer in terms of processes and programs. After processing, the service technician is shown the first test step of a tree structure with strict system management. He works through the test step tree successively. If you want to loosen up the system management, you can display the entire test tree or a defined sequence from it. In such a case, the service technician can decide for himself which test to choose next, whereby the tree always specifies the most efficient route. Loosening up the system management is particularly useful if special tools are required for the tests. If the required tool is not at hand, it may be advantageous to bring the follow-up test forward. After the test, the test tree must be corrected according to the result.

The workload of troubleshooting are failure candidates. These are represented by a data tuple consisting of the suspected component, the component's type of error, error status and error probability. A component is not necessarily a physical component, so that software or coding can also represent a fault candidate. The type of error is used in particular to find sporadic errors and is explained in detail in the description below.

With the help of the symptoms, the system determines the number of error candidates Ksym tom - This means all error candidates that affect the given symptom. A SPECIFIED the intact functions leads to the relieving amount -λK _Sym pto • Processing data internal to the vehicle results in a stressful candidate set K _{Fa rzeu} g and a relieving candidate set -ιK _Fa hrzeυg-

Another source of information is the remedy system TIPS / NEWS, as well as the vehicle history, which will only be integrated into the processing at a later point in time.

A candidate allocation takes place with the identified error candidates. This runs automatically on the diagnostic computer and in the background. The probabilities assigned to the individual error candidates are used in the calculation. The aim is to minimize the number of suspected error candidates, which must be checked in the further course of troubleshooting.

Error candidates of the sets

and -> K _Sym ptom form exclusion elements. With the help of the contained elements, previously suspected error candidates can be eliminated. The elimination takes place through a far lower probability. For the remaining error candidates, the elements of the intersection K _vehicle n K _sy mp _{to are} to be treated with the highest priority. Then the elements follow from sympto and finally those convincing from K _driving. The underlying metrics can be parameterized. Both the component and the type of error must be taken into account in the allocation. The result is an ordered list of error candidates K.

When integrating the TIPS and NEWS remedial systems, there are additional quantities that must be taken into account when troubleshooting. For a structured embedding of the systems, these should also provide error candidates that are included in the candidate invoice included. Fig. 10 illustrates the diagnostic process including the processing of TIPS or NEWS information from the remedial systems. After the vehicle-internal data has been read out and the standardized symptoms are present, the system starts a query with the TIPS and NEWS systems. If there are remedies to the given information, the database queries deliver the suspected error candidates contained in the remedies determined. These are included in the candidate allocation and processed, so that in the following step a test step tree can take into account the error candidates originating from TIPS or NEWS.

Alternatively, TIPS can serve as a pure information source. Instead of the further processable error candidates, TIPS then delivers a collection of documents. These are displayed to the service technician before entering the system-guided test.

With the help of the weighted error candidate list from the candidate allocation, the next step is to open the test tree. This step runs automatically and in the background. The algorithm accesses test step primitives that include individual tests including the fault candidates tested and the information required for the test, as well as the repair costs incurred. 11 shows this process step. The tree tries to minimize the troubleshooting time and the costs of the troubleshooting. It is important to open a tree that is as flat as possible. If the test tree is open, the service technician is shown the first test step and runs through the individual tests. With each check, error candidates are checked as OK or not OK. This means that the service technician further limits the error area and thus K with each test. If an examination leads to the exclusion of the tested error candidates, there is actually a discharge. According to this concept, this should not be done. The candidate should continue to exist, but is now treated as a sporadic candidate for errors. The exact background and the resulting process is explained below:

The test tree basically specifies the most efficient way of troubleshooting. This requirement should therefore be strictly followed wherever possible. If you want to give the service technician the freedom to select his next test step himself from the specified test tree, an iterative process is indispensable, as indicated by the dashed line in FIG. 10. Depending on the last test carried out, the test tree is corrected online so that an optimal route can be specified at any time.

Localization of sporadic errors

Sporadic errors can usually not be diagnosed because they cannot be reproduced. The main problem is that there is no mistake at the time of its review, which incorrectly relieves the candidate. In order to counteract this, the data tuples of the error candidates have an additional error status, which is switched from permanent to sporadic when the load is released.

Accordingly, the suspicion remains initially. The candidate must be checked (again) for sporadic suspicions. In the case of a line, this means, for example, that a continuity test is performed on the line that previously had a permanent exposure to the fault candidate with the type of interruption relieved. This leads to a change of status, so that the candidate management sporadically persists with the type of interruption and status. A further check for exactly this case only fully relieves the suspicion. The aim of the examination is to relieve the error candidate under sporadic suspicions. For example, this could be a continuity test on the line with the instruction to additionally wiggle the line.

Such tests are certainly associated with significantly higher costs, so that the tests are automatically used at a later time.

The customer can often already provide information on the error status. The information is taken into account accordingly when determining the error candidates in symptom processing. The information controls this suspicion. The test step database is to be expanded to include test steps for candidate testing on suspected sporadic errors. The algorithm when opening the test step tree coordinates their use.

Optional methods for locating non-reproducible errors

At this point, optional system extensions should be proposed.

In the workshop diagnosis known from the prior art, sporadic errors in particular play an important role. These errors are generally only detectable and identifiable at the time of their occurrence. If there is such a fault, the vehicle must remain in the workshop to understand the complaint. The customer loses confidence in the competence of the workshop and the product. If the vehicle is kept in the workshop, troubleshooting will immediately add additional costs with a replacement vehicle. The long-term effects of not using the customer's own vehicle are not clear at all. Troubleshooting often spans a weekend. The customer does not have his vehicle at hand while the workshop is not working on fault location. Systems that can follow what is happening inside the vehicle are therefore particularly in demand. Systems where the customer does not have to do without his vehicle while the workshop tries to find the fault have an additional attraction. The following optional system expansions of the diagnostic system described here provide considerable potential for improving the previously known diagnostic systems:

• Data logger: With the consent of the vehicle owner, a parameterizable data logger should be used. Depending on the symptom, the logger records important data that is later analyzed centrally or with a special workshop system. A converter to visualize the data in the workshop should be available. To save memory, the logger can be implemented as a ring buffer that records the data over a defined interval at the time of error detection. The ring buffer can also be used to record data before the error message. A defined error code or the response-on-event mechanism is suitable as a trigger.

• Remote diagnosis: The remote diagnosis is to be considered as a supplement to the data logger. The basis of the remote diagnosis is a temporarily integrable component (vehicle interface) that is passively involved in vehicle communication. In addition, further inputs are conceivable that tap physical measurement data directly from the vehicle. The component also contains a GSM Modem to transmit the vehicle data to an external diagnostic device or team.

The fault is localized offboard, while the customer does not have to do without his vehicle. The fault can be detected by nominal monitoring. Alternatively, vehicle events trigger the diagnostic process. The latter is based on processing regular system messages or the response-on-event mechanism in which the control unit reacts in an event-oriented manner.

Communication with the vehicle is carried out by the vehicle component or the external diagnostic device or team. In the future, UMTS can be used for the communication of larger amounts of data.

As already mentioned, the diagnosis can be made by a competent team with the help of the developer. Different procedures are available for the automatic diagnosis depending on the case. While rule-based or model-based procedures are available for static cases, evaluation of state machines or residual processing, for example, takes over the diagnosis of dynamic processes. An evaluation with state machines is based on the possibility of mapping the trajectories from state variables to non-deterministic or stochastic machines. If the state space is discretized, the system behaves in an event-discrete manner. Functional relationships can be shown in a causality graph or Bayes' network and evaluated accordingly.

Temporary onboard diagnosis. A temporary onboard diagnosis is another optional extension for represents the diagnostic system disclosed here, which can make a significant contribution to the localization of sporadic errors. It is integrated into the vehicle and takes over the system evaluation at runtime with all necessary boundary conditions.

Since today's restrictions regarding resources in the embedded area do not apply to temporary onboard diagnostics, their full potential can be exploited. Greater capacities of the available storage and computing resources, which are possible with temporarily installed devices, enable the knowledge bases to be expanded and model-based approaches to be used onboard in the vehicle, so that multiple errors can also be localized. Stochastic automatons or analyzes of causal relationships take over the diagnosis of dynamic or functional processes. The result of the onboard diagnosis can be read out again in the workshop and processed further. Alternatively, a combination of the temporary onboard diagnosis with the remote diagnosis is conceivable. The on-board diagnosis takes over the preprocessing or pre-evaluation in the vehicle and communicates the results to an external unit.

Claims

DaimlerChrysler AG patent claims

Computer-aided diagnostic system for technical devices with an executable diagnostic program, - which records error-specific technical system data of the technical device to be analyzed with an implemented evaluation algorithm, - which uses the evaluation algorithm with the acquired technical system data with a computer-processable model of the technical device and with a technical knowledge base , in which rule-based diagnostic knowledge about the technical device to be analyzed is stored for the computer-processable model, evaluated, interpreted and arrive at a diagnostic decision, the diagnostic decision containing a first set of error candidates, which indicates which parts of the technical device are suspected of being faulty that fault symptoms observed with a human-machine interface are recorded and mapped to a current, model-based symptom tree - and that the end value algorithm with symptom processing and a second symptom-based knowledge base evaluates and interprets the symptoms of the current, standardized symptom tree, and determines a second set of error candidates.

2. Diagnostic system according to claim 1, characterized in that at least one of the two sets of error candidates for the individual error candidates contains both stress characteristics and relief characteristics.

3. Diagnostic system according to claim 1 or 2, characterized in that the error symptoms are determined from a customer complaint.

4. Diagnostic system according to one of claims 1 to 3, characterized in that the evaluation algorithm offsets the first and the second set of error candidates.

5. Diagnostic system according to claim 4, characterized in that when the first and second set of error candidates are billed, those error candidates which contain relief features are discarded.

6. Diagnostic system according to claim 4, characterized in that when calculating the first and second set of error candidates, the average amount of both sets of error candidates is determined.

7. Diagnostic system according to one of claims 1 to 6, characterized in that a prioritization is carried out for the error candidates.

8. Diagnostic system according to one of claims 1 to 7, characterized in that a test step tree is spanned for the determined number of error candidates.

9. Diagnostic system according to one of claims 1 to 8, characterized in that the structure of the diagnostic system can be expanded by further evaluation algorithms and knowledge bases.

10. Diagnostic system according to one of claims 1 to 9, characterized in that with a remedial system (tips / news) a further set of error candidates is determined.

11. Diagnostic system according to claim 8, characterized in that the test step tree is spanned from test step primitives.

12. Diagnostic system according to one of claims 1 to 11, characterized in that a further knowledge base on the vehicle history is included in the determination of the quantity of error candidates by the evaluation algorithm.