WO2005111752A1 - Wissensbasiertes diagnosesystem für ein komplexes technisches system mit zwei getrennten wissensbasen zur verarbeitung technischer systemdaten und zur verarbeitung von kundenbeanstandungen - Google Patents
Wissensbasiertes diagnosesystem für ein komplexes technisches system mit zwei getrennten wissensbasen zur verarbeitung technischer systemdaten und zur verarbeitung von kundenbeanstandungen Download PDFInfo
- Publication number
- WO2005111752A1 WO2005111752A1 PCT/EP2005/004816 EP2005004816W WO2005111752A1 WO 2005111752 A1 WO2005111752 A1 WO 2005111752A1 EP 2005004816 W EP2005004816 W EP 2005004816W WO 2005111752 A1 WO2005111752 A1 WO 2005111752A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- error
- diagnostic system
- diagnostic
- symptom
- candidates
- Prior art date
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.
Landscapes
- Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Automation & Control Theory (AREA)
- Fuzzy Systems (AREA)
- Mathematical Physics (AREA)
- Quality & Reliability (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Testing And Monitoring For Control Systems (AREA)
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP05738120A EP1751637A1 (de) | 2004-05-15 | 2005-05-04 | Wissensbasiertes diagnosesystem für ein komplexes technisches system mit zwei getrennten wissensbasen zur verarbeitung technischer systemdaten und zur verarbeitung von kundenbeanstandungen |
US11/596,456 US20070226540A1 (en) | 2004-05-15 | 2005-05-04 | Knowledge-Based Diagnostic System for a Complex Technical System, Comprising Two Separate Knowledge Bases for Processing Technical System Data and Customer Complaints |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102004024262.3 | 2004-05-15 | ||
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 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2005111752A1 true WO2005111752A1 (de) | 2005-11-24 |
Family
ID=34966389
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2005/004816 WO2005111752A1 (de) | 2004-05-15 | 2005-05-04 | Wissensbasiertes diagnosesystem für ein komplexes technisches system mit zwei getrennten wissensbasen zur verarbeitung technischer systemdaten und zur verarbeitung von kundenbeanstandungen |
Country Status (4)
Country | Link |
---|---|
US (1) | US20070226540A1 (de) |
EP (1) | EP1751637A1 (de) |
DE (1) | DE102004024262A1 (de) |
WO (1) | WO2005111752A1 (de) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10703309B2 (en) | 2013-02-08 | 2020-07-07 | Bayerische Motoren Werke Aktiengesellschaft | Method and device for connecting a diagnostic unit to a control unit in a motor vehicle |
Families Citing this family (63)
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 |
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 |
US7643916B2 (en) | 2006-06-14 | 2010-01-05 | Spx Corporation | Vehicle state tracking method and apparatus for diagnostic testing |
US8762165B2 (en) | 2006-06-14 | 2014-06-24 | Bosch Automotive Service Solutions Llc | Optimizing test procedures for a subject under test |
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 |
US8428813B2 (en) | 2006-06-14 | 2013-04-23 | Service Solutions Us Llc | Dynamic decision sequencing method and apparatus for optimizing a diagnostic test plan |
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 |
WO2009067707A2 (en) * | 2007-11-21 | 2009-05-28 | Motive, Incorporated | Normalization engine and method of requesting a key-value pair of a device |
EP2238537A4 (de) * | 2008-01-29 | 2012-10-17 | Telcordia Tech Inc | System und verfahren für automatisierte verteilte diagnosen für netzwerke |
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 |
US8473089B2 (en) * | 2009-06-30 | 2013-06-25 | Lam Research Corporation | Methods and apparatus for predictive preventive maintenance of processing chambers |
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 |
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 |
US8538572B2 (en) * | 2009-06-30 | 2013-09-17 | Lam Research Corporation | Methods for constructing an optimal endpoint algorithm |
US8983631B2 (en) * | 2009-06-30 | 2015-03-17 | Lam Research Corporation | Arrangement for identifying uncontrolled events at the process module level and methods thereof |
US8618807B2 (en) * | 2009-06-30 | 2013-12-31 | Lam Research Corporation | Arrangement for identifying uncontrolled events at the process module level and methods thereof |
EP2284631A1 (de) * | 2009-07-17 | 2011-02-16 | Siemens Aktiengesellschaft | Verfahren zum Betrieb eines Fahrzeugdiagnosesystems, Steuerungsprogramm und Fahrzeugdiagnosesystem |
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 |
EP2778818B1 (de) * | 2013-03-12 | 2017-04-19 | Hitachi Ltd. | Identifikation von Fehlern in einem Zielsystem |
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 (en) * | 2014-04-01 | 2015-10-08 | Scania Cv Ab | Fault tracing of vehicles |
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 |
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 |
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 (de) * | 2018-09-18 | 2021-11-10 | Siemens Schweiz AG | Diagnosesystem und -verfahren mit parallelen analysepfaden |
CN110110401B (zh) * | 2019-04-19 | 2020-02-04 | 深圳市德塔防爆电动汽车有限公司 | 一种基于安全树模型的电动车辆安全设计优化方法 |
PL3966650T3 (pl) | 2019-05-09 | 2024-07-08 | Dürr Systems Ag | Sposób kontroli i obróbki dodatkowej elementów obrabianych, instalacja kontrolna oraz instalacja obróbkowa |
DE112020002294A5 (de) | 2019-05-09 | 2022-03-03 | Dürr Systems Ag | Analyseverfahren und Vorrichtungen hierzu |
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é |
US12020217B2 (en) | 2020-11-11 | 2024-06-25 | Cdk Global, Llc | Systems and methods for using machine learning for vehicle damage detection and repair cost estimation |
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 | 广州亚美信息科技有限公司 | 确定车辆故障次数的方法、装置、计算机设备和存储介质 |
US12045212B2 (en) | 2021-04-22 | 2024-07-23 | Cdk Global, Llc | Systems, methods, and apparatuses for verifying entries in disparate databases |
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 | 重庆科创职业学院 | 计算机排障系统 |
US11983145B2 (en) | 2022-08-31 | 2024-05-14 | Cdk Global, Llc | Method and system of modifying information on file |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5442555A (en) * | 1992-05-18 | 1995-08-15 | Argonne National Laboratory | Combined expert system/neural networks method for process fault diagnosis |
DE19523483A1 (de) * | 1995-06-28 | 1997-01-02 | Daimler Benz Ag | Rechnergestützte Fehlerdiagnoseeinrichtung für ein komplexes technisches System |
US5596712A (en) * | 1991-07-08 | 1997-01-21 | Hitachi, Ltd. | Method and system for diagnosis and analysis of products troubles |
WO2003042770A1 (en) * | 2001-11-16 | 2003-05-22 | Abb Ab | Provision of data for analysis |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US544255A (en) * | 1895-08-06 | Baling-press | ||
US5715374A (en) * | 1994-06-29 | 1998-02-03 | Microsoft Corporation | Method and system for case-based reasoning utilizing a belief network |
-
2004
- 2004-05-15 DE DE102004024262A patent/DE102004024262A1/de not_active Withdrawn
-
2005
- 2005-05-04 US US11/596,456 patent/US20070226540A1/en not_active Abandoned
- 2005-05-04 EP EP05738120A patent/EP1751637A1/de not_active Withdrawn
- 2005-05-04 WO PCT/EP2005/004816 patent/WO2005111752A1/de active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5596712A (en) * | 1991-07-08 | 1997-01-21 | Hitachi, Ltd. | Method and system for diagnosis and analysis of products troubles |
US5442555A (en) * | 1992-05-18 | 1995-08-15 | Argonne National Laboratory | Combined expert system/neural networks method for process fault diagnosis |
DE19523483A1 (de) * | 1995-06-28 | 1997-01-02 | Daimler Benz Ag | Rechnergestützte Fehlerdiagnoseeinrichtung für ein komplexes technisches System |
WO2003042770A1 (en) * | 2001-11-16 | 2003-05-22 | Abb Ab | Provision of data for analysis |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10703309B2 (en) | 2013-02-08 | 2020-07-07 | Bayerische Motoren Werke Aktiengesellschaft | Method and device for connecting a diagnostic unit to a control unit in a motor vehicle |
Also Published As
Publication number | Publication date |
---|---|
US20070226540A1 (en) | 2007-09-27 |
EP1751637A1 (de) | 2007-02-14 |
DE102004024262A1 (de) | 2005-12-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2005111752A1 (de) | Wissensbasiertes diagnosesystem für ein komplexes technisches system mit zwei getrennten wissensbasen zur verarbeitung technischer systemdaten und zur verarbeitung von kundenbeanstandungen | |
DE602005004997T2 (de) | Diagnostisches Verfahren und System | |
DE102011117803B4 (de) | Verfahren für die Wartungsdiagnose- und Wartungsprozedurverbesserung | |
DE19523483C2 (de) | Rechnergestützte Fehlerdiagnoseeinrichtung für ein komplexes technisches System | |
DE19742446B4 (de) | Fehlerdiagnoseverfahren | |
DE10307342B4 (de) | Vorrichtung und Verfahren zur modellbasierten On-Board-Diagnose | |
WO2006105930A1 (de) | Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben | |
DE102005027378B3 (de) | Dynamische Priorisierung von Prüfschritten in der Werkstattdiagnose | |
WO2002013015A1 (de) | System zur ermittlung von fehlerursachen | |
DE102012223393A1 (de) | Verfahren und System für die Grundursachenanalyse und Qualitätsüberwachung von Fehlern auf Systemebene | |
DE4305522C2 (de) | Einrichtung zur rechnergestützten Diagnose eines aus Modulen bestehenden technischen Systems | |
EP2146262A1 (de) | Verfahren zum Bestimmen fehlerhafter Komponenten in einem System | |
DE102007010978A1 (de) | Verfahren und Vorrichtung zur Unterstützung einer Diagnose eines elektrischen Systems mittels wahrscheinlichkeitsbasierter Fehlerkandidatenermittlung | |
DE102019217613A1 (de) | Verfahren zur diagnose eines motorzustands und diagnostisches modellierungsverfahren dafür | |
DE102005040142A1 (de) | Verfahren zur Identifikation komplexer Diagnosesituationen im Kundendienst | |
WO2008095518A1 (de) | Anwendung einer verteilten diagnosearchitektur in autosar | |
DE102011086352A1 (de) | Verfahren und Diagnosesystem zur Unterstützung der geführten Fehlersuche in technischen Systemen | |
DE102018209108A1 (de) | Schnelle Fehleranalyse für technische Vorrichtungen mit maschinellem Lernen | |
DE102004019151A1 (de) | Rechnergestütztes Diagnosesystem auf der Basis von Heuristiken und System-Topologien | |
WO2003029978A2 (de) | Verfahren und system zur bearbeitung von fehlerhypothesen | |
DE10315344B4 (de) | Verfahren und Vorrichtung zur Erkennung fehlerhafter Komponenten in Fahrzeugen | |
DE102008004219A1 (de) | Verfahren zum Behandeln mindestens eines Fehlers innerhalb eines Systems | |
DE102023115307B3 (de) | Verfahren zum Betreiben eines Fahrzeugs, Verfahren zum Entwickeln einer Einheit für ein Kraftfahrzeug sowie Kraftfahrzeug | |
WO2007065585A1 (de) | Diagnoseverfahren und diagnosevorrichtung zur funktionsorientierten diagnose eines systems mit vernetzten komponenten | |
DE102018212801A1 (de) | Diagnose komplexer Systeme |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2005738120 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWW | Wipo information: withdrawn in national office |
Country of ref document: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 11596456 Country of ref document: US Ref document number: 2007226540 Country of ref document: US |
|
WWP | Wipo information: published in national office |
Ref document number: 2005738120 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 11596456 Country of ref document: US |