EP1751637A1 - Systeme de diagnostic base sur les connaissances pour un systeme technique complexe pourvu de deux bases de connaissances separees pour le traitement de donnees techniques de systeme et de reclamations de clients - Google Patents

Systeme de diagnostic base sur les connaissances pour un systeme technique complexe pourvu de deux bases de connaissances separees pour le traitement de donnees techniques de systeme et de reclamations de clients

Info

Publication number
EP1751637A1
EP1751637A1 EP05738120A EP05738120A EP1751637A1 EP 1751637 A1 EP1751637 A1 EP 1751637A1 EP 05738120 A EP05738120 A EP 05738120A EP 05738120 A EP05738120 A EP 05738120A EP 1751637 A1 EP1751637 A1 EP 1751637A1
Authority
EP
European Patent Office
Prior art keywords
error
diagnostic system
diagnostic
symptom
candidates
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05738120A
Other languages
German (de)
English (en)
Inventor
Martin Konieczny
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
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 EP1751637A1 publication Critical patent/EP1751637A1/fr
Withdrawn legal-status Critical Current

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/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0243—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
    • G05B23/0245—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model based on a qualitative model, e.g. rule based; if-then decisions
    • G05B23/0248—Causal models, e.g. fault tree; digraphs; qualitative physics
    • 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
    • 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
    • G05B2223/00—Indexing scheme associated with group G05B23/00
    • G05B2223/04—Detection of intermittent failure

Definitions

  • 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.
  • 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 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.
  • 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.
  • 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.
  • model-based system diagnosis in the sense of this invention, is disclosed in detail in EP 1 069 487 B1, for example.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the diagnostic system is initially divided into seven modules:
  • 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.
  • 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.
  • TIPS / NEWS • TIPS / NEWS.
  • the database is based on known and clearly identifiable errors.
  • the request is based on the currently available input data.
  • FIG. 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.
  • 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.
  • 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.
  • 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.
  • the targeted error candidate check and thus the systematic error localization takes place.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • CAN-B components 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.
  • 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.
  • 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.
  • CBR standalone reasoning
  • 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
  • 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.
  • the system 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.
  • FIG. 6 illustrates the basic expandability of the diagnostic system by further modules.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the diagnostic system can optionally further restrict the amount of error candidates by recommending a test step tree to the service technician.
  • 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.
  • 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
  • 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.
  • test step tree shows the error as a function of the previously determined number of error candidates, taking into account the standing costs localized.
  • 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
  • dependencies of the tests must be taken into account in order to be able to adhere to the necessary sequences.
  • 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 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.
  • test step primitives 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the data tuples of the error candidates have an additional error status, which is switched from permanent to sporadic when the load is released.
  • the suspicion remains initially.
  • the candidate must be checked (again) for sporadic suspicions.
  • 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.
  • 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.
  • 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.
  • 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.
  • vehicle interface vehicle interface
  • 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.
  • 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.
  • UMTS can be used for the communication of larger amounts of data.
  • 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 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.

Abstract

Le système de diagnostic selon la présente invention supporte la localisation des défaillances se produisant de manière intermittente par l'inclusion desdites défaillances dans un diagnostic temporaire à bord ou dans un diagnostic temporaire à distance avec évaluation subséquente à l'atelier. L'avantage essentiel de ce procédé réside dans le fait que le client n'a pas besoin de renoncer à son véhicule pendant la localisation de la défaillance.
EP05738120A 2004-05-15 2005-05-04 Systeme de diagnostic base sur les connaissances pour un systeme technique complexe pourvu de deux bases de connaissances separees pour le traitement de donnees techniques de systeme et de reclamations de clients Withdrawn EP1751637A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004024262A DE102004024262A1 (de) 2004-05-15 2004-05-15 Wissensbasiertes Diagnosesystem für ein komplexes technisches System mit zwei getrennten Wissensbasen zur Verarbeitung technischer Systemdaten und zur Verarbeitung von Kundenbeanstandungen
PCT/EP2005/004816 WO2005111752A1 (fr) 2004-05-15 2005-05-04 Systeme de diagnostic base sur les connaissances pour un systeme technique complexe pourvu de deux bases de connaissances separees pour le traitement de donnees techniques de systeme et de reclamations de clients

Publications (1)

Publication Number Publication Date
EP1751637A1 true EP1751637A1 (fr) 2007-02-14

Family

ID=34966389

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05738120A Withdrawn EP1751637A1 (fr) 2004-05-15 2005-05-04 Systeme de diagnostic base sur les connaissances pour un systeme technique complexe pourvu de deux bases de connaissances separees pour le traitement de donnees techniques de systeme et de reclamations de clients

Country Status (4)

Country Link
US (1) US20070226540A1 (fr)
EP (1) EP1751637A1 (fr)
DE (1) DE102004024262A1 (fr)
WO (1) WO2005111752A1 (fr)

Families Citing this family (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005027378B3 (de) * 2005-06-14 2006-11-16 Daimlerchrysler Ag Dynamische Priorisierung von Prüfschritten in der Werkstattdiagnose
US8266272B2 (en) * 2005-11-07 2012-09-11 Hewlett-Packard Development Company, L.P. Methods for IT network representation and associated computer program products
DE102006018831A1 (de) * 2006-04-22 2007-10-25 Daimlerchrysler Ag Kraftfahrzeugdiagnose und Fahrzeugannahme
US7643916B2 (en) 2006-06-14 2010-01-05 Spx Corporation Vehicle state tracking method and apparatus for diagnostic testing
US9081883B2 (en) 2006-06-14 2015-07-14 Bosch Automotive Service Solutions Inc. Dynamic decision sequencing method and apparatus for optimizing a diagnostic test plan
US8428813B2 (en) 2006-06-14 2013-04-23 Service Solutions Us Llc Dynamic decision sequencing method and apparatus for optimizing a diagnostic test plan
US8423226B2 (en) 2006-06-14 2013-04-16 Service Solutions U.S. Llc Dynamic decision sequencing method and apparatus for optimizing a diagnostic test plan
US8762165B2 (en) 2006-06-14 2014-06-24 Bosch Automotive Service Solutions Llc Optimizing test procedures for a subject under test
US7958407B2 (en) * 2006-06-30 2011-06-07 Spx Corporation Conversion of static diagnostic procedure to dynamic test plan method and apparatus
DE102006039690A1 (de) * 2006-08-24 2008-02-28 Bayerische Motoren Werke Ag Fahrzeugdaten-Erfassungssystem
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
DE102007034151A1 (de) 2007-07-21 2009-01-22 Daimler Ag Funktionsorientierte Fehlerdiagnose von Kraftfahrzeugen
EP2215775A1 (fr) * 2007-11-21 2010-08-11 Motive, Incorporated Système et procédé pour identifier et appeler une fonction d'un service
CA2713736A1 (fr) * 2008-01-29 2009-08-06 Telcordia Technologies, Inc. Systeme et procede de diagnostics distribues automatises pour des reseaux
US8239094B2 (en) 2008-04-23 2012-08-07 Spx Corporation Test requirement list for diagnostic tests
US8280835B2 (en) * 2009-01-29 2012-10-02 Telcordia Technologies, Inc. Method for automated distributed diagnostics for networks
US8648700B2 (en) 2009-06-23 2014-02-11 Bosch Automotive Service Solutions Llc Alerts issued upon component detection failure
US8271121B2 (en) * 2009-06-30 2012-09-18 Lam Research Corporation Methods and arrangements for in-situ process monitoring and control for plasma processing tools
US8538572B2 (en) * 2009-06-30 2013-09-17 Lam Research Corporation Methods for constructing an optimal endpoint algorithm
US8618807B2 (en) * 2009-06-30 2013-12-31 Lam Research Corporation Arrangement for identifying uncontrolled events at the process module level and methods thereof
US8983631B2 (en) * 2009-06-30 2015-03-17 Lam Research Corporation Arrangement for identifying uncontrolled events at the process module level and methods thereof
US8473089B2 (en) * 2009-06-30 2013-06-25 Lam Research Corporation Methods and apparatus for predictive preventive maintenance of processing chambers
US8295966B2 (en) * 2009-06-30 2012-10-23 Lam Research Corporation Methods and apparatus to predict etch rate uniformity for qualification of a plasma chamber
EP2284631A1 (fr) * 2009-07-17 2011-02-16 Siemens Aktiengesellschaft Procédé de fonctionnement d'un système de diagnostic de véhicule, programme de commande et système de diagnostic de véhicule
DE102009053753B4 (de) 2009-11-18 2017-03-30 Audi Ag Verfahren zum Ermitteln der Ursache eines Fehlers an einem Kraftfahrzeug
JP5564941B2 (ja) * 2009-12-28 2014-08-06 富士通株式会社 障害箇所推定システム、障害箇所推定装置および障害箇所推定方法
US8595553B2 (en) * 2010-06-03 2013-11-26 Siemens Aktiengesellschaft Error pattern identification in an installed base of systems
US8751777B2 (en) 2011-01-28 2014-06-10 Honeywell International Inc. Methods and reconfigurable systems to optimize the performance of a condition based health maintenance system
US8615773B2 (en) 2011-03-31 2013-12-24 Honeywell International Inc. Systems and methods for coordinating computing functions to accomplish a task using a configuration file and standardized executable application modules
FR2973902B1 (fr) * 2011-04-06 2019-06-07 Dassault Aviation Procede d'analyse de pannes presentes sur une plateforme et systeme associe
US8990770B2 (en) 2011-05-25 2015-03-24 Honeywell International Inc. Systems and methods to configure condition based health maintenance systems
US8726084B2 (en) * 2011-10-14 2014-05-13 Honeywell International Inc. Methods and systems for distributed diagnostic reasoning
US8832649B2 (en) 2012-05-22 2014-09-09 Honeywell International Inc. Systems and methods for augmenting the functionality of a monitoring node without recompiling
US8832716B2 (en) 2012-08-10 2014-09-09 Honeywell International Inc. Systems and methods for limiting user customization of task workflow in a condition based health maintenance system
US9037920B2 (en) 2012-09-28 2015-05-19 Honeywell International Inc. Method for performing condition based data acquisition in a hierarchically distributed condition based maintenance system
DE102013202064A1 (de) 2013-02-08 2014-08-14 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zum Verbinden eines Diagnosegeräts mit einem Steuergerät in einem Kraftfahrzeug
EP2778818B1 (fr) * 2013-03-12 2017-04-19 Hitachi Ltd. Identification de défauts dans un système cible
US11080734B2 (en) 2013-03-15 2021-08-03 Cdk Global, Llc Pricing system for identifying prices for vehicles offered by vehicle dealerships and other entities
US9092332B2 (en) * 2013-05-02 2015-07-28 Microsoft Technology Licensing, Llc Activity based sampling of diagnostics data
GB2522484B (en) * 2014-03-07 2016-02-10 Testplant Ltd Method and system for creating reference data for an automated test of software with a graphical user interface
WO2015152803A1 (fr) * 2014-04-01 2015-10-08 Scania Cv Ab Suivi de pannes de véhicules
US10867285B2 (en) 2016-04-21 2020-12-15 Cdk Global, Llc Automatic automobile repair service scheduling based on diagnostic trouble codes and service center attributes
US10853769B2 (en) 2016-04-21 2020-12-01 Cdk Global Llc Scheduling an automobile service appointment in a dealer service bay based on diagnostic trouble codes and service bay attributes
US10621061B2 (en) * 2016-11-28 2020-04-14 B. G. Negev Technologies amd Applications Ltd. at Ben-Gurion University Combined model-based approach and data driven prediction for troubleshooting faults in physical systems
US11501351B2 (en) * 2018-03-21 2022-11-15 Cdk Global, Llc Servers, systems, and methods for single sign-on of an automotive commerce exchange
US11190608B2 (en) 2018-03-21 2021-11-30 Cdk Global Llc Systems and methods for an automotive commerce exchange
CN109087282A (zh) * 2018-07-02 2018-12-25 北京百度网讯科技有限公司 显示屏外围电路检测方法、装置、电子设备及存储介质
DE102018212801A1 (de) * 2018-08-01 2020-02-06 Bayerische Motoren Werke Aktiengesellschaft Diagnose komplexer Systeme
EP3627261B1 (fr) * 2018-09-18 2021-11-10 Siemens Schweiz AG Système et procédé de diagnostique en parallèle
CN110110401B (zh) * 2019-04-19 2020-02-04 深圳市德塔防爆电动汽车有限公司 一种基于安全树模型的电动车辆安全设计优化方法
EP3966650B1 (fr) 2019-05-09 2024-03-06 Dürr Systems AG Procédé de contrôle et de post-traitement de pièces, installation de contrôle et installation de traitement
EP3966649A1 (fr) 2019-05-09 2022-03-16 Dürr Systems AG Procédé d'analyse et dispositifs pour celui-ci
DE102019206837A1 (de) * 2019-05-10 2020-11-12 Dürr Systems Ag Analyseverfahren und Vorrichtungen hierzu
JP7430040B2 (ja) * 2019-07-10 2024-02-09 株式会社日立製作所 故障箇所特定支援システム
DE102020106545A1 (de) * 2020-03-11 2021-09-16 Bayerische Motoren Werke Aktiengesellschaft Diagnosesystem für Kraftfahrzeuge
FR3110721B1 (fr) * 2020-05-20 2022-06-03 Thales Sa Procédé et dispositif électronique de détermination d'une liste d'action(s) de maintenance, programme d'ordinateur associé
US11080105B1 (en) 2020-11-18 2021-08-03 Cdk Global, Llc Systems, methods, and apparatuses for routing API calls
US11514021B2 (en) 2021-01-22 2022-11-29 Cdk Global, Llc Systems, methods, and apparatuses for scanning a legacy database
CN113127804B (zh) * 2021-03-10 2023-03-21 广州亚美信息科技有限公司 确定车辆故障次数的方法、装置、计算机设备和存储介质
US11803535B2 (en) 2021-05-24 2023-10-31 Cdk Global, Llc Systems, methods, and apparatuses for simultaneously running parallel databases
CN113342609A (zh) * 2021-06-10 2021-09-03 重庆科创职业学院 计算机排障系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US544255A (en) * 1895-08-06 Baling-press
JP2985505B2 (ja) * 1991-07-08 1999-12-06 株式会社日立製作所 品質情報収集診断システム及びその方法
US5442555A (en) * 1992-05-18 1995-08-15 Argonne National Laboratory Combined expert system/neural networks method for process fault diagnosis
US5715374A (en) * 1994-06-29 1998-02-03 Microsoft Corporation Method and system for case-based reasoning utilizing a belief network
DE19523483C2 (de) * 1995-06-28 1998-10-22 Daimler Benz Ag Rechnergestützte Fehlerdiagnoseeinrichtung für ein komplexes technisches System
GB0127553D0 (en) * 2001-11-16 2002-01-09 Abb Ab Provision of data for analysis

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005111752A1 *

Also Published As

Publication number Publication date
WO2005111752A1 (fr) 2005-11-24
DE102004024262A1 (de) 2005-12-01
US20070226540A1 (en) 2007-09-27

Similar Documents

Publication Publication Date Title
EP1751637A1 (fr) Systeme de diagnostic base sur les connaissances pour un systeme technique complexe pourvu de deux bases de connaissances separees pour le traitement de donnees techniques de systeme et de reclamations de clients
DE602005004997T2 (de) Diagnostisches Verfahren und System
DE19523483C2 (de) Rechnergestützte Fehlerdiagnoseeinrichtung für ein komplexes technisches System
DE19742446B4 (de) Fehlerdiagnoseverfahren
WO2006105930A1 (fr) Systeme de diagnostic pour etablir une liste ponderee d'elements eventuellement defectueux a partir de donnees d'un vehicule et d'indications d'un client
DE10307342B4 (de) Vorrichtung und Verfahren zur modellbasierten On-Board-Diagnose
DE10244131B4 (de) Verfahren zur Unterstützung einer Identifizierung einer defekten Funktionseinheit in einer technischen Anlage
DE102005027378B3 (de) Dynamische Priorisierung von Prüfschritten in der Werkstattdiagnose
WO2002013015A1 (fr) Systeme de determination d'origines d'erreur
DE102012223393A1 (de) Verfahren und System für die Grundursachenanalyse und Qualitätsüberwachung von Fehlern auf Systemebene
EP0685086B1 (fr) Dispositif permettant de produire automatiquement une base de connaissances pour un system expert de diagnostic
EP2146262A1 (fr) Procédé de détermination de composants défectueux dans un système
DE102019135608A1 (de) Verfahren, Vorrichtung und System zur Detektion von anomalen Betriebszuständen eines Geräts
DE102019217613A1 (de) Verfahren zur diagnose eines motorzustands und diagnostisches modellierungsverfahren dafür
WO2008095518A1 (fr) Utilisation d'une architecture de diagnostic distribué dans autosar
DE102011086352A1 (de) Verfahren und Diagnosesystem zur Unterstützung der geführten Fehlersuche in technischen Systemen
DE102005040142A1 (de) Verfahren zur Identifikation komplexer Diagnosesituationen im Kundendienst
DE102018209108A1 (de) Schnelle Fehleranalyse für technische Vorrichtungen mit maschinellem Lernen
DE102004019151A1 (de) Rechnergestütztes Diagnosesystem auf der Basis von Heuristiken und System-Topologien
EP1451689A2 (fr) Procede et systeme de traitement d'hypotheses d'erreurs
DE10315344B4 (de) Verfahren und Vorrichtung zur Erkennung fehlerhafter Komponenten in Fahrzeugen
DE102008004219A1 (de) Verfahren zum Behandeln mindestens eines Fehlers innerhalb eines Systems
WO2007065585A1 (fr) Procede et dispositif de diagnostic oriente fonction d'un systeme comportant des composants mis en reseau
DE102018212801A1 (de) Diagnose komplexer Systeme
DE10213895A1 (de) Diagnosemodul

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20061109

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: DAIMLERCHRYSLER AG

RIN1 Information on inventor provided before grant (corrected)

Inventor name: KONIECZNY, MARTIN

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: DAIMLER AG

17Q First examination report despatched

Effective date: 20081020

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

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20120705