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 PDF

Info

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
Application number
PCT/EP2005/004816
Other languages
English (en)
French (fr)
Inventor
Martin Konieczny
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
Priority to EP05738120A priority Critical patent/EP1751637A1/de
Priority to US11/596,456 priority patent/US20070226540A1/en
Publication of WO2005111752A1 publication Critical patent/WO2005111752A1/de

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/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

Das erfindungsgemässe Diagnose­system unterstützt die Lokalisierrung der in­termittierend auftretenden Fehler durch Mitprotokollieren in einer temporären Onboard-Diagnose oder einer temporären Ferndiagnose mit anschliessender Auswertung in der Werkstatt Der wesentliche Vorteil dieser Methode liegt in der Tatsache, dass der Kunde während der Fehlerlokalisierung nicht auf sein Fahrzeug verzichten muss.

Description

DaimlerChrysler AG
Wissensbasiertes Diagnosesystem für ein komplexes technisches System mit zwei getrennten Wissensbasen zur Verarbeitung technischer Systemdaten und zur Verarbeitung von Kundenbeanstandungen
Die Erfindung betrifft ein Diagnosesystem aus der Kategorie der modellbasierten Systemdiagnose. Bei diesen rechnergestützten Diagnosesystemen wird das zu analysierende technische System mit einem rechnerverarbeitbaren Modell abgebildet und mittels Sensoren und
Fehlererkennungsalgorithmen auf auftretende Fehler überwacht. Die Fehler werden kodifiziert und mittels einer Wissensbasis, die das zur rechnergestützten Diagnose relevante Diagnosewissen enthält, und einem Diagnosesystem ausgewertet. Die Auswertung basiert hier im wesentlichen auf dem festgestellten Fehlercode und das Diagnosesystem ermittelt aus der Wissensbasis die dem Fehlercode zugeordnete Fehlerkandidatenmenge. In einem weiteren Schritt wird die Anzahl der Fehlerkandidaten durch Heranziehen von sogenannten Fehlerumgebungsdaten, also von während des Auftretens des Fehlers vorliegenden weiteren Systemdaten, und deren Berücksichtigung mittels' fehlerspezifischer Ausschlusskriterien von dem Diagnosesystem auf ein Minimum reduziert. Alternativ können die verbleibenden Fehlerkandidaten noch von dem Diagnosesystem bewertet und gewichtet werden. Derartige Modellbasierte Diagnosesysteme sind in verschiedenen Ausprägungen aus dem Stand der Technik bekannt.
In der DE 195 23 483 AI ist ein modellbasiertes, rechnergestütztes Diagnosesystem entsprechend dem Oberbegriff des unabhängigen Anspruchs bekannt, bei dem die Modellbildung ein Strukturmodell und ein Wirkungsmodell, das oft auch als Verhaltensmodell bezeichnet wird, umfasst. Mit dem Strukturmodell werden die physikalischen Zusammenhänge der einzelnen Komponenten des technischen Systems abgebildet und mit dem Verhaltensmodell werden die Funktionen der einzelnen Komponenten des technischen Systems abgebildet. In einer Wissensbasis ist das für die Diagnose relevante Diagnosewissen abgespeichert. Mit dem Diagnosesystem kann eine Fehlererkennung und durch Rückgriff auf die Wissensbasis eine rechnergestützte Fehlersuche durchgeführt werden. Das Diagnosesystem selbst hat hierbei nur und ausschließlich Zugriff auf Fehlerumgebungsdaten aus dem technischen System und auf eine Wissensbasis, die ausschließlich auf die fehlerspezifische Auswertung der technischen Systemdaten abstellt. Kundenbeanstandungen oder symptomatische Fehlerbeschreibungen können nur durch eine von einem erfahrenen Servicetechniker ausgeübte Menusteuerung berücksichtigt werden, wenn aus den technischen Systemdaten und den Fehlerumgebungsdaten keine eindeutige Diagnose oder überhaupt keine Diagnose durch das Diagnosesystem möglich ist .
Eine andere Möglichkeit der Modellbildung, wie sie unter dem Begriff der modellbasierten Systemdiagnose im Sinne dieser Erfindung verstanden wird und geeignet ist, ist beispielsweise in der EP 1 069 487 Bl ausführlich offenbart. Hier wird das zu diagnostizierende technische System für die rechnergestützte Diagnose mit einem Wahrscheinlichkeitsnetz, einem sogenannten Bayes Netzwerk abgebildet und modelliert. Eine Modellbildung mit Wahrscheinlichkeitsnetzen hat den Vorteil, das die Modellbildung auf funktionaler Ebene der einzelnen Komponenten des Systems erfolgen kann. Die einzelnen Komponenten selbst brauchen nicht bis auf ein physikalisches Strukturmodell modelliert werden. Allerdings erkauft man sich diesen Vorteil mit dem Problem die richtigen Apriori Wahrscheinlichkeiten des Bayes Netzwerkes aufzufinden. Entsprechend einer aufgefundenen Fehlermeldung wird mittels einer Wissensbasis eine die Systemzustände abbildende Wahrscheinlichkeitsverteilung innerhalb des Wahrscheinlichkeitsnetzwerkes berechnet und daraus mit einem Diagnosesystem eine Fehleraussage getroffen und eine zu dieser Fehleraussage passende Abhilfemaßnahme vorgeschlagen. Um das Diagnoseergebnis zu verbessern sind im Wahrscheinlichkeitsnetz Frageknoten integriert, die es ermöglichen über eine Mensch Maschine Schnittstelle während des Diagnoseablaufs an einen Benutzer des Diagnosesystems einfache Ja/Nein-Fragen zu stellen. Durch Beantwortung der Fragen wird im Diagnoseablauf an entscheidenden Netzwerknoten evidentes Wissen abgefragt und in den Diagnoseablauf eingeführt, so dass sich das Diagnoseergebnis mit Hilfe dieses evidenten Wissens entscheidend verbessert. Allerdings kann lediglich evidentes Wissen eingepflegt werden, dessen Abfrage vom Systemdesigner vorgesehen war und in Form eines Frageknotens in die Modellbildung implementiert wurde. Nach Einbindung des abgefragten evidenten Wissens wird unter dessen Berücksichtigung und unter Berücksichtigung einer Wissensbasis, die die funktionalen technischen Zusammenhänge der einzelnen Komponenten des technischen Systems enthält, eine Wahrscheinlichkeitsverteilung innerhalb des Netzwerkes berechnet und daraus auf die wahrscheinlichste Fehlerursache geschlossen. Der Modellierungsaufwand bei der modellbasierten Systemdiagnose ist hoch. Insbesondere hängt die Qualität des Diagnoseergebnisses entscheidend von der Modellierung ab. Man sucht deshalb auch nach Alternativen zur modellbasierten Systemdiagnose. Eine derartige Alternative ist ein symptombasierter Ansatz, wie er beispielsweise in der DE 102 35 416 AI beschrieben wird. Beim symptombasierten Ansatz wird auf eine Modellierung des technischen System verzichtet. Stattdessen werden einfache z.B. akustische Symptome aufgezeichnet und mit bereits bekannten Mustern verglichen. Findet sich zu einem auftretenden Symptom ein bekanntes Muster, so ist der Diagnoseprozess weitgehend beendet. Man untersucht dann die dem aufgefundenen Muster zugeordnete Fehlerkandidatenmenge bis man den exakten Fehler gefunden hat.
Ein Problem bei allen vorbeschriebenen rechnergestützten Diagnosesystemen ist, dass sie lediglich in der Lage sind, vordefinierte und damit bekannte Fehlermeldungen und Beanstandungen zu verarbeiten. Dies macht auch die aufwendige Modellierung notwendig, da immer versucht werden muss, alle möglichen Komplikationen schon beim Design des Diagnosesystems zu erfassen und abzubilden. Und selbst dann ist es nicht möglich Kundenbeanstandungen, die naturgemäß ohne technische Detailkenntnisse nur symptomhaft beschrieben werden, rechnergestützt zu verarbeiten und für den Diagnoseprozess nu nutzen.
Dies hat zwei entscheidende Nachteile. Zum einen besteht die Gefahr, dass der Fehlerraum, in dem die Fehlerkandidatenmenge zu suchen ist, nicht weit genug aufgespannt wird. Diese Gefahr ist immer dann besonders groß, wenn ein von einem Kunden berichteter Fehler intermittierend, also nur gelegentlich und nicht dauerhaft auftritt. Solche Fehler können von bekannten rechnergestützten Diagnosesystem nicht gefunden werden, da sie auf da's Vorliegen eines Fehlercodes angewiesen sind und den Fehlerraum um den Fehlercode herum aufspannen.
Der zweite Nachteil liegt in dem Informationsverlust, der auftritt wenn die Kundenerfahrung nicht genutzt oder nur ungenügend berücksichtigt wird. Diese Kundenerfahrung mit einem auftretenden Fehlersymptom kann nämlich bei richtig aufgespanntem Fehlerraum und bei richtig identifizierter Fehlerkandidatenmenge dazu genutzt werden, die Menge der identifizierten Fehlerkandidaten weiter einzuschränken. Beispielsweise kann zu einer „Fehlerkandidatenmenge „Sitzsteuerung defekt" mit einer Kundenbeanstandung „der Sitz lässt sich nur noch nach oben fahren" rechnergestützt ausgeschlossen werden, dass der Stellmotor der Sitzmechanik defekt ist .
Erfindungsgemäße Aufgabe ist es daher, bestehende modellbasierte Diagnosesysteme dahin gehend zu erweitern, dass von Kunden berichtete Symptome mit in den rechnergestützten Diagnoseablauf integriert werden und beim Diagnoseablauf rechnergestützt verarbeitet werden.
Die Aufgabe wird gelöst mit einem Diagnosesystem mit den Merkmalen des unabhängigen Anspruchs. Vorteilhafte Ausführungsformen der Erfindung sind in den Unteransprüchen und in der Beschreibung der Ausführungsbeispiele offenbart.
Die Lösung gelingt hauptsächlich indem ein bekanntes modellbasiertes Diagnosesystem mit einem zweiten symptombasierten Zweig und einer zweiten Wissensbasis ergänzt wird, die mit Hilfe eines Symptombaumes mit den Kundenbeanstandungen gefüllt wird. Der Symptombaum ist notwendig, um den Wortlaut der originalen Kundenbeanstandung, in maschinell verarbeitbare Aussagen umzusetzen, die vom Diagnosesystem rechnergestützt interpretiert werden können. So werden mit dem Symptombaum zu einem in der Kundenbeanstandung im Originalwortlaut enthaltenen Symptom weitere Informationen in der Symptomumgebung dieses Symptom abgefragt. Von besonderen Interesse sind hierbei Informationen darüber, welche Funktionen bei einer gemeldeten Kundenbeanstandung in der Symptomumgebung intakt sind. Da dies auf schnelle und einfache Weise eine Verbesserung des Diagnoseergebnisses während einer abschließenden Bewertung erlaubt. Diese abschließende Bewertung ist hierbei als Fehlerkandidatenverrechnung ausgebildet. Es wird zunächst mit dem rein modellbasierten Zweig des Diagnosesystems eine erste Fehlerkandidatenmenge ermittelt . Dann wird mit dem symptombasierten Zweig des Diagnosesystems eine zweite Fehlerkandidatenmenge errechnet. Die zweite
Fehlerkandidatenmenge kann insbesondere Angaben zu vom Kunden als intakt gemeldete Fehlerkandidaten enthalten. Am Schluss werden die beiden Fehlerkandidatenmengen miteinander verrechnet, indem die Fehlerkandidaten ausgeschlossen werden, die nicht gleichzeitig in beiden Fehlerkandidatenmengen als defekt diagnostiziert sind.
In einer Ausführungsform erfolgt die
Fehlerkandidatenverrechnung durch Ausschließen der in einer der beiden Fehlerkandidatenmengen als intakt gemeldeten Fehlerkandidate .
In einer alternativen Ausführungsform erfolgt die Fehlerkandidatenverrechnung durch Schnittmengenbildung. Es werden lediglich diejenigen Fehlerkandidaten berücksichtigt, die in beiden Fehlerkandidatenmengen gleichzeitig vorhanden sind. In einer alternativen Ausführungsform, die für modellbasierte Diagnosesysteme auf der Basis von Bayesnetzen geeignet ist, erfolgt in beiden Fehlerkandidatenmengen eine Priorisierung der einzelnen Fehlerkandidaten. Bei der Fehlerkandidatenverrechnung werden dann diejenigen Fehlerkandidaten ermittelt, die aus beiden Fehlerkandidatenmengen die größte Summenpriorität haben.
Die mit der Erfindung hauptsächlich erzielten Vorteile liegen in einer verbesserten Diagnose. Mit dem System ist es möglich Kundenbeanstandungen im Originalton zu verarbeiten. Die Verarbeitung der Kundenbeanstandung kann hierbei bei der Abarbeitung des Symptombaumes bereits in Zusammenarbeit mit dem Kunden oder auch erst nachträglich durch Abarbeiten des Symptombaumes durch einen Servicetechniker in der Servicewerkstatt erfolgen.
Ein weiterer Vorteil der Erfindung liegt darin, das mit dem symptombasierten Zweig des Diagnosesystems auch intermittierend auftretende Fehler bearbeitet werden können. Auch ist es ein Vorteil, dass der symptombasierte Zweig des Diagnosesystems nicht an irgendwelche Fehlercodes gebunden ist, die bei rein modellbasierten DiagnoseSystemen notwendig sind und von Steuergeräten geliefert werden müssen.
In einer weiteren vorteilhaften Ausführungsform des Diagnosesystems wird nach Ermittlung der Fehlerkandidaten der dann in der Werkstatt erforderliche Prüfschrittbaum von dem Diagnosesystem aus vordefinierten und abgespeicherten Prüfschrittprimitiven zusammengesetzt und gebildet. Das ermöglicht ein mit dem Diagnosefortschritt dynamisches Aufspannen eines möglichst flachen und breiten Prüfschrittbaumes zur Unterstützung des Servicetechnikers in der Servicewerkstatt .
Ein Ausführungsbeispiel eines erfindungsgemäßen Diagnosesystems wird im folgen anhand von Figuren näher erläutert .
Dabei zeigen:
Fig. 1 ein Datenflussdiagramm des Diagnosesystems,
Fig. 2 eine Systemarchitektur,
Fig. 3 die Symptomverarbeitung,
Fig. 4 die Verarbeitung fahrzeuginterner Daten,
Fig. 5 die Fehlerkandidatengenerierung,
Fig. 6 die Verarbeitung weiterer Eingangsdaten,
Fig. 7 die Fehlerkandidatenverrechnung,
Fig. 8 das Aufstellen des Prüfschrittbaumes,
Fig. 9 die Fehlerkandidatenmengen im Fehlerraum,
Fig. 10 einen Gesamtablauf des Diagnoseverfahrens,
Fig. 11 das Aufspannen des Prüfschrittbaumes aus Prüfschrittprimitiven.
Das nachfolgende Beschreibung offenbart den modularen Systemaufbau und die Funktionalitäten der einzelnen Module. Das genaue Zusammenspiel der einzelnen Bestandteile bei der Fehlersuche ist ebenfalls dargestellt.
Systemarchitektur
Um die Anforderungen nach einer bestmöglichen Flexibilität, Erweiterbarkeit, Wartbarkeit und Nutzung aktueller Techniken zur Fehlerlokalisierung erfüllen zu können, ist das Diagnosesystem zunächst in sieben Module eingeteilt:
• Verarbeitung fahrzeuginterner Daten (als Erweiterung der heutigen Systemdiagnose) . Das Diagnosesystem wertet fahrzeuginterne Informationen automatisch zur Fehlerkan- didatengenerierung aus. Fahrzeugdaten können Fehlerkandidaten belasten und entlasten.
• Symptomeinstieg. Die Überführung der Kundenbeanstandung, also der originalen Problembeschreibung seitens des Kunden, in eine technische Problembeschreibung in standardisierter Form wird als Symptomeinstieg bezeichnet. Nennt der Kunde intakte Funktionalitäten, so müssen auch diese in einer geeigneten Form ebenfalls standardisiert werden.
• Symptomverarbeitung. Basierend auf den Informationen des DMS (Dealer Management System) sowie des Symptomeinstiegs werden Fehlerkandidaten generiert. An dieser Stelle kann auch die Verarbeitung der Kundenaussagen bezüglich intakter Funktionen erfolgen.
• Fehlerkandidatenverrechnung. Die aus der Symptomverarbeitung, der Verarbeitung fahrzeuginterner Daten und ggf. aus weiteren vorangehenden Informationsverarbeitungen generierten Fehlerkandidaten sind miteinander zu verrechnen. Die Verrechnung ermittelt eine Menge von Fehlerkandidaten einschließlich einer Gewichtung der einzelnen Elemente.
• Dynamisches Aufspannen von Prüfschrittbäumen. Die ermittelten Fehlerkandidaten sind systematisch zu überprüfen. Hierzu wird ein Prüfschrittbaum gemäß der Fehlerkandidaten dynamisch aufgespannt. Die systematische Überprüfung orientiert sich an Kosten und Informationsgehalt einzelner Prüfschritt-Primitive . Der Grad der Benutzerführung entscheidet letztendlich, ob der Baum einmalig aufzu- spannen ist, oder ob er ggf. nach jeder durchgeführten Prüfung zu korrigieren ist .
• Verarbeitung der Fahrzeughistorie. Zu jedem Werkstatt- aufenthalt des Fahrzeuges existiert ein Bericht mit den getauschten Komponenten etc. Diese Daten können die Fehlersuche vereinfachen, da die Wahrscheinlichkeit einer fehlerhaften Komponente als Ursache mit jedem Tausch dieser Komponente sinkt.
• TIPS/NEWS. Vor der systematischen Fehlerlokalisierung mit Hilfe der geführten Fehlersuche wird eine Anfrage nach bestehenden Abhilfen an das TIPS/NEWS-System gestartet. Bekannte und eindeutig identifizierbare Fehler liegen der Datenbank zugrunde. Die Anfrage basiert auf den aktuell vorliegenden Eingangsdaten.
Fig. 1 zeigt den Datenfluss der gesamten Informationsverarbeitung anhand der ersten fünf Module obiger Aufzählung. Die Verarbeitung der Fahrzeughistorie ist an dieser Stelle aus Gründen der Übersicht zunächst weggelassen. TIPS und NEWS werden weiter unten separat behandelt.
Als Eingangsdaten stehen die Informationen aus dem Fahrzeug und die Kundenbeanstandung zur Verfügung. Nach der dargestellten Verarbeitung liegt ein aufgespannter Prüfschrittbaum vor, der abzuarbeiten ist.
Fig. 2 zeigt den Datenfluss anhand der zu verarbeitenden Mengen. Gleichzeitig lässt sich die Systemarchitektur der Fehlerlokalisierung erkennen.
Die Systemarchitektur ist durch einen modularen Aufbau mit definierten Schnittstellen geprägt. Die Einzelnen Komponenten sind austauschbar und weiterentwickelbar . Durch die Austauschmöglichkeit können die einzelnen Verarbeitungsschritte dem Stand der Technik angepasst werden. Im Unterschied zu Fig. 1 ist die Verarbeitung der Fahrzeughistorie in die Darstellung integriert. Sie ist ein zu der Symptomverarbeitung und der Verarbeitung fahrzeuginterner Daten paralleler Zweig. Gleichermaßen sind weitere Dateneingänge möglich, die alle eine Informationsart auf Fehlerkandidaten abbilden.
Im Wesentlich gibt Fig. 2 gleichzeitig den Ablauf wieder, der von oben nach unten zu lesen ist. Die Verarbeitung der fahrzeuginternen Daten, des Symptoms und der Fahrzeughistorie können automatisch und parallel arbeiten. Die Ergebnisse aller drei Verarbeitungen sind Fehlerkandidatenmengen, die zu verrechnen sind. Im letzten Schritt findet die gezielte Fehlerkandidatenüberprüfung und damit die systematische Fehlerlokalisierung statt.
Die einzelnen Komponenten des Diagnosesystems : Jedes Modul ist durch sein äußeres Verhalten bestimmt. Die Eingangs- und Ausgangsdaten sind klar festgelegt. Für die Datenverarbeitung innerhalb der einzelnen Module können verschiedene Techniken genutzt werden.
Modul Symptomeinstieg (und Kundenangabe)
Der Symptomeinstieg dient der Standardisierung der Kundenbeanstandung in Form des Orginaltons zur maschinellen Weiterverarbeitung. Für die Eingliederung der Begriffe ist ein eindeutiger Symptombaum heranzuziehen. Dieser verfeinert die Begriffe (Symptome) nach einer funktionalen Betrachtungsweise. Alternativ kann durchaus ein spezieller MMI-Symptombaum (Mensch-Maschine. Interface) , der in Form eines Thesaurus oder eines Lexikons die Begriffe aus dem Originalton der Kundenbeanstandung auf die technischen Fachbegriffe des Werkstattpersonals abbildet, für die Schnittstelle zum Kunden verwendet werden. Der MMI -Symptombaum ist dadurch gekennzeichnet, dass die Kundenaussage über mehrere Wege klassifiziert werden kann. So zählt ein Abstandsradar beispielsweise sowohl zu dem Motor als auch zum Fahrkomfort oder den Bedienelementen im Innenraum. Da für die weitere Verarbeitung ein eindeutiges Symptom gefordert ist, existiert eine Zuordnung der Einträge aus dem MMI-Symptombaum zu dem eindeutigen (tatsächlichen) Symptombaum. Tabelle 0-1 stellt die wesentlichen Charakteristiken des Symptomeinstiegs dar.
Bei der manuellen Standardisierung navigiert der Servicetechniker durch den Symptombaum. Der Servicetechniker kann die Standardisierung in beliebiger Stufe aufhören. Hört der Servicetechniker an einer relativ hohen Stufe auf, so liefert das unpräzise Symptom einen relativ großen Fehlersuchraum. Aus diesem Grund strebt die Reparaturannahme eine möglichst detaillierte Aussage des Kunden an.
Prinzipiell kann der Symptomeinstieg unmittelbar bei der Fahrzeugannahme erfolgen. Hierzu sind entsprechende Funktionalitäten des Diagnosesystems bereitzustellen. Liegt vor dem Symptomeinstieg oder zum Zeitpunkt des Symptomeinstiegs die Verbindung zum Fahrzeug vor, kann eine Hervorhebung der zu den Fahrzeugdaten konsistenten Symptome stattfinden. Dieser Mechanismus wird bei der Symptomverarbeitung weiter unten näher betrachtet .
Eine wichtige Erweiterung des Symptomeinstiegs ist die äquivalente Verarbeitung einer Angabe der intakt funktionierenden Einheiten durch den Kunden. Auch diese Angabe muss standardisiert werden. Außerdem sollte der Kunde bei seiner Beanstandung ebenfalls die Angabe machen, ob die Beanstandung dauerhaft oder sporadisch auftritt. In Abhängigkeit dieser Angabe werden zum Teil unterschiedliche Fehlerkandidaten belastet, insbesondere ändert sich aber die Art der Belastung und damit die weitere Vorgehensweise bei der Fehlersuche. Eine Detaillierte Angaben zur Lokalisierung sporadischer Fehler ist weiter unten in der Beschreibung angegeben. Tabelle 0-1: Charakteristiken des Symptomeinstiegs
Figure imgf000015_0001
Als Verarbeitungsmethode ist bei dem Symptomeinstieg bewusst die manuelle Zuordnung angegeben zwischen dem MMI- Sysmptombaum und dem Sysmptombaum, der letztlich von dem Diagnosesystem zur Fehlersuche benutzt wird. Prinzipiell gibt es viele Mechanismen, die eine automatische Klassifizierung und Zuordnung von semantischen Begriffen vornehmen. Allerdings bringen automatische Verfahren in der Regel eine weitere Unscharfe in die Fehlersuche, da sie mit Ähnlichkeitskriterien arbeiten. Zu Empfehlen ist daher an dieser Stelle eine manuelle Standardisierung der Kundenbeanstandung, insbesondere bei Anwesenheit des Kunden.
Selbstverständlich kann der Kunde auch mehrere Symptome nennen, die den Suchraum präzisieren oder sich auf Mehrfachfehler beziehen. Darüber hinaus ist die optionale Angabe einwandfreie funktionierender Systeme gewünscht aber nicht zwingend notwendig. Letztere führen letztendlich zu einer Fehlerkandidateneinschränkung .
In Zusammenarbeit mit der Symptomverarbeitung ist ein Dialog realisierbar, der die Eingabe der Kundenbeanstandung leitet. Wird beispielsweise das Symptom „Sitzverstellung vorne/hinten" eingegeben, so ermittelt die Symptomverarbeitung alle passenden Fehlerkandidaten. Ausgehend von den Fehlerkandidaten lassen sich wiederum alle Symptome ermittelt, die mindestens einen dieser Fehlerkandidaten enthalten. Der Kunde wird nach diesen Symptomen gefragt und kann sich zu ihnen äußern, indem er angibt, ob das Symptom dauerhaft vorhanden, sporadisch vorhanden oder nicht vorhanden ist. Hierdurch wird der Suchraum eingeschränkt . Gibt der Kunde hierzu keine oder nur teilweise Angaben, verschlechtert sich die Fehlersuche u. U. entsprechend, da der Suchraum größer wird.
Symptomverarbeitung
Bei der Symptomverarbeitung findet eine Abbildung des standardisierten Symptoms auf Fehlerkandidaten statt. In gleicher Art und Weise werden Kundenangaben verarbeitet, die sich auf einwandfrei funktionierende Teile beziehen. Mit Hilfe letzterer Angabe kommt es zu einer Entlastung von Fehlerkandidaten. Zwar wird folglich lediglich die reine Symptomverarbeitung beschrieben, die Darstellung bezieht sich aber in gleicher Weise auf die Kundenangaben der intakten Funktionen.
Um die richtigen Wissensbasen auszuwerten, sind die Fahrzeugdaten, insbesondere die Fahrzeugidentifikationsnummer FIN, e- benfalls anzugeben bzw. aus den Kontex Informationen der aktuellen Fehlersuche auszulesen und zu berücksichtigen. Da das Symptom auf der Kundenbeanstandung basiert, handelt es sich um unscharfes, respektive unsicheres Wissen.
Zur Verarbeitung des Symptoms können unterschiedliche Methoden eingesetzt werden. Raum, F.; Schreier, N.; Spöttl, G. : „Die Zukunft computergestützter Kfz-Diagnose. Rechnergeführte Handlangerarbeit oder qualifizierte Facharbeit." , erschienen im Bertelsmann Verlag, Bielefeld 2002, enthält eine Gegenüberstellung verschiedener Techniken. U. a. eignet sich beispielsweise das Case based reasoning (CBR) , da hierbei eine unscharfe Verarbeitung stattfindet. Beim CBR wird versucht anhand definierter Ähnlichkeiten den aktuell vorliegenden Fall aus einem bereits bekannten Fall herzuleiten. Eine andere Möglichkeit und sehr anschauliche Methode ist eine regel-orientierte Verarbeitung. In den Regeln können die Beziehungen zwischen einem Symptom und den möglichen Fehlerkandidaten in einfacher Weise abgelegt werden. Allerdings sind dem auf Dauer Grenzen gesetzt, da lediglich ein direkter Zusammenhang zwischen den beiden Informationsarten Symptom und Fehlerkandidat möglich ist. In komplexen Systemen lässt sich der Zusammenhang nicht unmittelbar in Beziehung bringen, da eigentlich ein komplexes Zusammenspiel vieler Funktionalitäten vorliegt.
Ein Umweg über Funktionsmodelle ist für komplexe technische Systeme daher empfehlenswert. Eine geeignete Technik ist an dieser Stelle der Einsatz von Bayes' sehen Netzen, die eine Modellierung der Zusammenhänge zwischen Symptomen und Fehlerkandidaten über beliebige Netzwerke zulassen.
Tabelle 0-2 fasst den Verarbeitungsschritt der Symptomverarbeitung zusammen.
Tabelle 0-2: Charakteristiken der Symptomverarbeitung
Figure imgf000017_0001
Eine wichtige Eigenschaft der vorgesehenen Symptomverarbeitung ist die Möglichkeit einer Kandidatenverrechnung aufgrund von Mehrfacheingaben. Viele Fehler wirken sich in verschiedenen Kundenbeanstandungen gleichzeitig aus. Ein Beispiel hierfür ist eine durchgebrannte Sicherung. Liegt ein solcher Fehlerfall vor, sind gleichzeitig mehrere Funktionalitäten gestört. Sind seitens des Kunden einige von ihnen bekannt, können sie die Fehlersuche signifikant beschleunigen.
Für die Symptomverarbeitung ist zusätzlich der Symptombaum (ggf. MMI -Symptombaum o. ä.) notwendig. Dies hat den Vorteil, dass ein Symptom nicht immer bis auf die kleinste Differenzierungsstufe klassifiziert werden kann. Ist das Symptom nur auf einer höheren (unsch rferen) Klassifizierungsstufe bekannt, so werden alle darunter liegenden Symptome bei der Abbildung auf die Fehlerkandidaten herangezogen.
Mit Hilfe der Symptomverarbeitung und des Symptomeinstiegs lässt sich ein Dialog zur Minimierung der Fehlersuchzeiten realisieren.
Verarbeitung fahrzeuginterner Informationen
Bei der Verarbeitung fahrzeuginterner Daten erfolgt die Berechnung von Fehlerkandidaten anhand der gespeicherten Fehlercodes und ihrer Umgebungsdaten, der Fahrzeugkonfiguration sowie der zur Verfügung stehenden Ist-Werte des Fahrzeuges. Ist das Symptom bekannt, erfolgt die Auswertung der relevanten Steuergeräte. Hierzu ist nach Möglichkeit ein Zusammenhang zwischen dem standardisierten Symptom und den betroffenen Steuergeräten bereitzustellen. Mit Hilfe derartiger Informationen müssten nicht alle fahrzeuginternen Daten betrachtet werden, sondern eine Fokussierung auf den relevanten Teil erfolgen. Die Fokussierung auf die relevanten Steuergeräte schafft eine signifikante Beschleunigung bei der Komu- nikation und damit im gesamten Prozesses. Tabelle 0-3 fasst die Verarbeitung fahrzeuginterner Informationen zusammen.
Tabelle 0-3: Charakteristiken der Verarbeitung fahrzeuginterner Daten
Figure imgf000019_0001
Fig. 4 stellt die Verarbeitung der fahrzeuginternen Daten graphisch dar. Momentan findet die Verarbeitung fahrzeuginterner Daten onboard statt . Sie umfasst die Diagnose von CAN- B-Komponenten sowie von CAN-Leitungsfehlern. Zur BR 221 ist eine Erweiterung der Diagnose auf alle CAN- und Most- Komponenten vorgesehen. Ab BR 204 findet die Verarbeitung ausschließlich offboard statt. In der BR171 soll der CAN-C- Bereich offboard abgedeckt werden, während der CAN-B-Bereich onboard verarbeitet wird. Das modulare Konzept erlaubt den vorgesehenen Entwicklungsprozess .
Die heutige Onboard-Diagnose (Systemdiagnose) arbeitet regelorientiert und muss aufgrund der zur Verfügung stehenden Ressourcen in ihrem Umfang und ihrer Diagnosetiefe stark eingeschränkt werden. Dadurch schöpft man nicht ihr volles Potential aus. Auf der anderen Seite erfolgt eine situationsbedingte Be- und Entlastung statt. Durch eine Verlagerung der Verarbeitung fahrzeuginterner Daten gehen u. U. wichtige In- formationen verloren, was zu kompensieren ist. Auf der anderen Seite steht wesentlich mehr Performance zur Verfügung, so dass dieser Verarbeitungsteil bestmöglich ausgeschöpft werden kann.
Die automatische Verarbeitung fahrzeuginterner Informationen kann auch Offboard realisiert werden, wenn entsprechende Schnittstellen im und zum Fahrzeug bereitgestellt werden. Für die automatische Verarbeitung sind problemspezifisch unterschiedliche Verfahren geeignet. Einsetzbar ist beispielsweise eine regelorientierte oder modellbasierte Verarbeitung. Strukturelle Modellanalysen auf physikalischen Modellen erlauben eine Problemdekomposition sowie die Untersuchung der Diagnostizierbarkeit .
Graphentheoretische Ansätze ermöglichen eine Topologieauswer- tung zur Ermittlung der am Fehler beteiligter Komponenten o- der Funktionsgruppen. Die zur Verfügung stehenden Ressourcen sowie der Grad einer Wissens-Vorverarbeitung entscheiden über den Einsatz der jeweiligen Technik. Aufgrund der definierten Schnittstelleninformationen sind die Methoden austauschbar und ein multimodales Diagnoseverfahren konfigurierbar.
Methoden des Case based Reasoning können ebenfalls zum Einsatz kommen. In Fig. 5 wird auf diesen Aspect mit einer graphischen Darstellung näher eingegangen. Bei den Systemen TIPS und NEWS handelt es sich um eigenständige Softwarekomponenten des Case based reasoning (CBR) , die in die Fehlerlokalisierung eingebunden sind. Der zu Beginn vorliegende Datensatz, bestehend aus den fahrzeuginternen Informationen sowie den Symptom- und Fahrzeugdaten, wird an die Systeme TIPS und NEWS übergeben. Die Systeme durchsuchen die eigenen Wissensbasen nach zu den Eingangsdaten passenden Fällen. Liegt ein derartiger Fall vor, signalisiert das System das Vorhandensein einer Abhilfe. Im einfachsten Fall kann die Abhilfe direkt ausgegeben werden, was allerdings nicht zu empfehlen ist, da die systematische Fehlersuche nicht mehr gegeben ist. Viel wichtiger ist die Nutzung der zusätzlichen Informationen für eine gezielte und systematische Fehlersuche.
Tabelle 0-4: Charakteristiken der Datenbankabfragen in TIPS und NEWS während der Fehlerlokalisierung
Figure imgf000021_0001
Grundsätzlich ist die Eindeutigkeit der Suchergebnisse nicht gewährleistet, so dass die Datenbankabfrage u. U. mehr als eine Abhilfe liefert. Da mit jeder Abhilfe prinzipiell Fehlerkandidaten repariert oder getauscht werden, können die Abhilfen mit Sicherheit auf Fehlerkandidaten abgebildet werden, so dass sie im Falle einer mehrdeutigen Lösung eine Menge an Fehlerkandidaten resultieren. Mit Hilfe der fallspezifischen Prüfbaumau Spannung kann die Fehlerkandidatenmenge im weiteren Verlauf der Fehlersuche systematisch eingegrenzt werden. An dieser Stelle ist eine Einbindung der Ergebnisse von TIPS bzw. NEWS in das hier beschriebene Diagnosesystem notwendig. Die entsprechenden Schnittstellen zwischen der geführten Fehlerlokalisierung und den Systemen TIPS und NEWS sind zu spezifizieren. Tabelle 0-4 beschreibt die wichtigsten Charakteristiken des gesamten Verarbeitungsschrittes in der Fehlerlokalisierung. Für eine vollständige Integration von TIPS muss das System im Falle einer gefundenen Abhilfe die zugrunde liegenden Fehlerkandidaten mitteilen. Anschließend kann das hier konzipierte Verfahren die Fehlerkandidaten entsprechend gewichtet gleichermaßen wie alle anderen Fehlerkandidaten behandeln. Fig. 10 veranschaulicht die vollständige Integration von TIPS/NEWS in das Diagnosesystem.
Des Weiteren enthält das System NEWS Reparaturanleitungen, Schadenschlüssel zur Abrechnung sowie Ersatzteilnummern. Die entsprechenden Informationen werden nach erfolgreicher Fehlerlokalisierung referenziert .
Verarbeitung der Fahrzeughistorie und weiterer Eingangsdaten Fig. 6 veranschaulicht die prinzipielle Erweiterungsfähigkeit des Diagnosesystems um weitere Module. Besonders interessant ist hierbei die Einbindung von Datenbanken, die Informationen zur Fahrzeughistorie und damit Informationen über bereits ausgeführte Reparaturen und Wartungen enthalten. Die Fahrzeughistorie beinhaltet Informationen zu bereits durchgeführten Reparaturen und ist nur bedingt für die Fehlerlokalisierung nutzbar. U. a. gehen Beanstandungen sowie die getauschten Komponenten aus der Fahrzeughistorie hervor. Wurde vor kurzer Zeit eine Komponente getauscht, so ist die Wahrscheinlichkeit relativ gering, dass bei gleicher Kundenbeanstandung die bereits getauschte Komponente die Ursache darstellt. Vielmehr wird es sich bei der getauschten Komponente um einen Folgefehler oder einen In-Ordnung-Ausbau handeln. Dies bedeutet, dass die nun verdächtigte Komponente zwar durchaus wieder defekt sein kann, sie aber nicht die Ursache der Kundenbeanstandung ist. Tabelle 0-5: Charakteristiken der Verarbeitung der Fahrzeughistorie
Figure imgf000023_0001
Die Auswertung der Fahrzeughistorie beschränkt sich hauptsächlich auf eine Datenbankabfrage. Basierend auf den Fahrzeugdaten, die der Identifizierung des Fahrzeuges dienen, liefert die Abfrage die bereits getauschten Komponenten. Diese können u. U. einer Entlastung von Fehlerkandidaten bei der aktuellen Fehlersuche dienen.
Eine Integration der Verarbeitung der Fahrzeughistorie soll an dieser Stelle als Option für das Diagnosesystem gesehen werden. Gleiches gilt für weitere, hier nicht näher spezifizierte Verfahren, die z.B. den Verschleißstatus oder das Eingangsdatum von Komponentenins Fahrzeug auf Fehlerkandidaten abbilden. Somit veranschaulicht Fig. 6 die allgemeingültige Erweiterungsfähigkeit des Diagnosesystems um weitere Module dar.
Kandidatenverrechnung Die Kandidatenverrechnung übernimmt die Reduzierung der zu betrachtenden Fehlerkandidaten. Gleichzeitig werden die zu betrachtenden Fehlerkandidaten priorisiert. Es findet somit eine Eingrenzung und Bewertung des Fehlersuchraumes statt. Fig. 7 veranschaulicht den Verarbeitungsprozess der Kandida- tenverrechnung anhand der wichtigsten beteiligten Fehlermengen.
Ausgangspunkt der Verrechnung bilden die zuvor auf den fahrzeuginternen Daten sowie auf der Kundenbeanstandung basierend ermittelten Mengen der Belastungs- (KFahrzeug, Ksymptom, ( KTIPS, KNEWS) ) und Entlastungskandidaten {—ιKFahrzeug ,
Figure imgf000024_0001
• Für die Kandidatenverrechnung ist im ersten Schritt ein para- metrierbarer Algorithmus implementiert, der auf bestehenden Diagnosealgorithmen aus dem Stand der Technik auf der Basis von Komponentenerkennung Fehlerarterkennung durch Fehlercodes aufbaut. Diese bestehenden Diagnosesysteme und deren Algorithmen werden um folgende Aspekte erweiter :
• Belastungskandidaten, die sowohl in der Komponente als auch in der Fehlerart übereinstimmen und sowohl aus dem Symptom als auch aus der Verarbeitung fahrzeuginterner Daten resultieren, bilden die wahrscheinlichsten Fehlerursache .
• Innerhalb der Schnittmenge (KFahrzeug n Ksymptom) , die die Komponente sowie die Fehlerart berücksichtigt, erfolgt eine Gewichtung gemäß der aus den vorangehenden Verarbeitungsschritten vorliegenden Wahrscheinlichkeiten.
• Ein Kandidat der Entlastungsmenge ->KFahrze g oder -ιKSymptom entlastet einen korrespondierenden Belastungskandidaten, sofern Komponente und Fehlerart übereinstimmen.
• Bei unterschiedlichen Fehlerarten einer Komponente kann eine vollständige Entlastung eines Fehlerkandidaten nur dann stattfinden, wenn entsprechende Entlastungskandidaten der Komponente in allen möglichen Fehlerarten vorliegen. Eine geeignete Wissensbasis ist bereitzustellen.
• Liegt eine Belastung einer Komponente mit unterschiedlichen Fehlerarten seitens des Symptoms und seitens der Verarbeitung fahrzeuginterner Daten vor, so ist die Belastung des Fehlerkandidaten aus der Verarbeitung fahrzeuginterner Daten höher zu gewichten.
Als weitere Option kann der Algorithmus durch Methoden für mehrdimensionale Optimierungsprobleme verbessert werden. Tabelle 0-6 charakterisiert die Kandidatenverrechnung, wobei neben den bereits genannten Mengen auch die Fehlerkandidaten aus den Abhilfesystemen TIPS und/oder NEWS berücksichtigt werden. Existieren in TIPS und/oder NEWS zu den gegebenen Eingangsdaten Abhilfen, so sind diese mit den verdächtigten Fehlerkandidaten zu versehen. Die Kandidatenverrechnung übernimmt die Integration der Daten.
Tabelle 0-6: Charakteristiken der Kandidatenverrechnung
Figure imgf000025_0001
Fallspezifische Generierung des Prüfbaums
Ist die Kandidatenverrechnung zu einem Ergebnis gekommen und hat eine Fehlerkandidatenmenge ermittelt, so kann mit dem Diagnosesystem optional die Fehlerkandidatenmenge weiter eingeschränkt werden, indem dem Servicetechniker ein Prüfschrittbaum empfohlen wird. Mit Hilfe der Prüfschritte soll die Fehlerkandidatenmenge unter Berücksichtigung der Prüfkosten sys- te atisch eingegrenzt werden. Ziel ist eine möglichst schnelle Eingrenzung. Um eine überschaubare Modellierung der Prüfungen zu erzielen, sind die Prüfschritte als Primitive realisiert. Ein Primitiv ist hierbei z.B. eine Überprüfungsanweisung für die Funktionsüberprüfung einer im Kraftfahrzeug verbauten Komponente oder im Falle von allgemeinen Störungen, die mehrere Komponenten betreffen Der Algorithmus des Diagnosesystems übernimmt die Auswahl und Bewertung der Prüf- schritt-Primitive und spannt einen Prüfschrittbaum auf, der in der Werkstatt abgearbeitet wird. Die Aufspannung orientiert sich an
• der Menge (Anzahl) verdächtigter Fehlerkandidaten, • der Fehlerwahrscheinlichkeiten einzelner Fehlerkandidaten, • der Kosten einzelner Prüfungen, • einer schnellstmöglichen Eingrenzung des Fehlers.
Tabelle 0-7 zeigt die Charakteristiken der Prüfsehrittbaumge- nerierung. Fig. 8 und Fig. 10 veranschaulichen den Datenfluss und die Auswahl der Prüfschrittprimitive zur Aufspannung des Prüfschrittbaumes dar.
Tabelle 0-7: Charakteristiken der dynamischen Prüfschritte
Figure imgf000026_0001
Als Resultat liegt also ein Prüfschrittbaum in impliziter Form vor, der den Fehler in Abhängigkeit der zuvor ermittelten Fehlerkandidatenmenge unter Berücksichtigung der ent- stehenden Kosten lokalisiert. Für eine Realisierung der Fehlersuchstrategie muss die Struktur der Prüfschritt-Primitive die Elemente gemäß Tabelle 0-8 beinhalten.
Tabelle 0-8: Datenstruktur der Prüfschritt-Primitive
Figure imgf000027_0001
Darüber hinaus müssen Abhängigkeiten der Prüfungen berücksichtigt werden, um notwendige Reihenfolgen einhalten zu können. In Zukunft sollten die Prüfungen in vorangehende Arbeiten, Prüfung und nachfolgende Arbeiten getrennt werden. Zu den vorangehenden oder nachfolgenden Arbeiten gehören beispielsweise das Freilegen einer zu prüfenden Komponente. Der Algorithmus ist dann in der Lage, diese Tätigkeiten mit zu berücksichtigen. Damit können beispielsweise nach Ausbau einer Komponente alle Prüfungen durchgeführt werden, die diesen Ausbau voraussetzen.
Des Weiteren sind neben den Prüfschritt-Primitiven auch komplexere PrüfStrukturen mit mehreren Ausgängen und unterschiedlichen Aussagen bedatbar. Mit ihnen lassen sich komplexe, zusammenhängende Abläufe abbilden. Kontextabhängig werden die Strukturen, wie die Primitive, vom Algorithmus eingesetzt, so dass sich ein optimaler Ablauf für den Diagnoseprozess in der Werkstatt ergibt .
Fehlerlokalisierung
Das hier offenbarte Diagnosesystem verfolgt das Ziel einer geführten Fehlersuche. Die Führungs erfolgt in an sich bekannter weise mit einem Bildschirmmenu. Mit Sicherheit wird es auch die Möglichkeit eines Kurztests und damit der vollständigen Dateneinsicht geben. In einem solchen Fall, hat der Servicetechniker die Möglichkeit, an der Führung vorbei zu arbeiten Hierdurch entstehen heute enorme Kosten, weil der Servicetechniker mit diesen Optionen beliebige Freiräume bei der Fehlersuche hat und damit seine eigene Systematik bei der Fehlersuche ergreift. Außerdem kommt es sehr oft zu Verdachtsreparaturen. Auf der anderen Seite wird es immer einen Kurztest oder einen Zugang zu Diagnosedaten über eine Produktgliederung geben, da der Zugriff für einen Systemcheck o- der eine gezielte Erweiterung des Diagnosesystems zugänglich sein muss.
Aus diesen Gründen sollte der Auftrag bei der Kundenannahme über den Grad der Führung entscheiden. Ist ein Tausch einer vorher bestimmten Komponente gefordert, so können Diagnoseda- ten über einen festzulegenden aber direkten Zugriff erreicht werden. Ist der Fehler aber unbekannt und der Auftrag weist eine Fehlersuche auf, so muss der beschriebene Zugang untersagt werden und lediglich die geführte Fehlersuche zugänglich sein.
Gesamtablauf bei der Suche nach dauerhaft vorliegenden Fehlern
Dauerhaft vorliegende Fehler können mittels einer systematischen Auswertung der zur Verfügung stehenden Informationen unter Zuhilfenahme weiterer Messungen lokalisiert werden. An dieser Stelle soll der Gesamtablauf der Fehlersuche anhand der im Hintergrund verarbeiteten Datenmengen erläutert werden.
Geführte Fehlersuche
Fig. 9 veranschaulicht den Zusammenhang der einzelnen Fehlerkandidatenmenge unter Angabe der Diagnosemodul aus denen sie erzeugt wurden und deren Verhältnis zum gesamten Fehlersuchraum.
Während der Fahrzeugannahme werden die Fahrzeugdaten sowie die Kundenbeanstandungen erfasst. Damit liegt die Kundenbeanstandung als Originalwortlaut vor und ist auf standardisierte Symptome abzubilden. Für eine möglichst gute Eingrenzung des Fehlersuchraumes ist die Angabe mehrere Symptome möglich, da sich viele Fehler gleichzeitig in verschiedenen Symptomen auswirken. Die Differenzierung in ein dauerhaft oder sporadisch vorliegendes Symptom verhilft bei der Spezifizierung der Fehlerart. Grundsätzlich ist an dieser Stelle auch eine Angabe einwandfrei funktionierender Systemteile denkbar, die zu einer wesentlich schnelleren Fehlersuche durch Ausschluss von Fehlerkandidaten führen würde. Der Symptomeinstieg kann in der Fahrzeugannahme (Dealer Management System) erfolgen. Da es allerdings weltweit zwölf verschiedene AnnahmeSysteme gibt, ist der Symptomeinstieg in der Werkstatt gegebenenfalls durch den Servicetechniker manuell vorzunehmen .
Im Anschluss an die Symptomeingabe erfolgt eine Verarbeitung aller zur Verfügung stehenden Informationen. Die Auswertung findet auf dem Diagnoserechner ablauf- und programmtechnisch im Hintergrund statt. Nach der Verarbeitung bekommt der Servicetechniker bei strikter Systemführung den ersten Prüfschritt einer Baumstruktur angezeigt. Er arbeitet den Prüf- schrittbaum sukzessive ab. Will man die Systemführung auflockern, kann man den gesamten Prüfbaum oder eine definierte Sequenzen hieraus anzeigen. Der Servicetechniker kann in einem solchen Fall selber entscheiden, welche Prüfung er als nächstes wählt, wobei der Baum immer den effizientesten Weg vorgibt. Eine Auflockerung der Systemführung ist insbesondere dann sinnvoll, wenn für die Prüfungen spezielle Werkzeuge benötigt werden. Liegt das benötigte Werkzeug nicht griffbereit, so kann es von Vorteil sein, die Folgeprüfung vorzuziehen. Nach der Prüfung ist der Prüfbäum gemäß des Ergebnisses zu korrigieren.
Die Arbeitsmenge der Fehlersuche sind Fehlerkandidaten. Diese sind durch ein Daten-Tupel aus verdächtigter Komponente, Fehlerart der Komponente, Fehlerstatus und Fehlerwahrscheinlichkeit repräsentiert. Als Komponente ist nicht zwangsweise eine physikalische Komponente gemeint, so dass auch eine Software oder Codierung einen Fehlerkandidaten darstellen kann. Der Fehlerart dient insbesondere dem Auffinden sporadischer Fehler und wird weiter unten in der Beschreibung im Detail erläutert .
Mit Hilfe der Symptome ermittelt das System die Fehlerkandidatenmenge Ksym tom- Gemeint sind alle Fehlerkandidaten, die sich in dem vorgegebenen Symptom auswirken. Eine Angebe der intakten Funktionen führt zu der entlastenden Menge -λKSympto • Die Verarbeitung fahrzeuginterner Daten führt zu einer belastenden Kandidatenmenge KFa rzeug und einer entlastenden Kandidatenmenge —ιKFahrzeυg-
Eine weitere Informationsquelle ist das Abhilfesystem TIPS/NEWS, sowie die Fahrzeughistorie, die erst zu einem späteren Zeitpunkt in die Verarbeitung integriert wird.
Mit den ermittelten Fehlerkandidaten findet eine Kandidatenverrechnung statt . Diese läuft auf dem Diagnoserechner automatisch und im Hintergrund ab. Die zu den einzelnen Fehlerkandidaten zugeordneten Wahrscheinlichkeiten werden bei der Verrechnung herangezogen. Ziel ist eine möglichst kleine Menge an verdächtigten Fehlerkandidaten, die im weiteren Verlauf der Fehlersuche zu überprüfen ist.
Fehlerkandidaten der Mengen
Figure imgf000031_0001
und ->KSymptom bilden Ausschlusselemente. Mit Hilfe der enthaltenen Elemente können zuvor verdächtigte Fehlerkandidaten eliminiert werden. Die Eliminierung erfolgt über ein weites Herabsetzen der Wahrscheinlichkeit. Für die verbleibenden Fehlerkandidaten sind die Elemente der Schnittmenge KFahrzeug n KSympto mit höchster Priorität zu behandeln. Dann folgen die Elemente aus sympto und schließlich diejenigen aus KFahrzeug. Die zugrundeliegenden Metriken sind parametrierbar . Bei der Verrechnung sind sowohl Komponente als auch Fehlerart zu berücksichtigen. Als Ergebnis liegt eine geordnete Liste von Fehlerkandidaten K vor.
Bei Integration der Abhilfesysteme TIPS und NEWS gibt es weitere Mengen, die bei der Fehlersuche zu berücksichtigen sind. Für eine strukturierte Einbettung der Systeme, sollten diese ebenfalls Fehlerkandidaten liefern, die in die Kandidatenver- rechnung einbezogen werden. Fig.10 veranschaulicht den Diagnoseablauf einschließlich der Verarbeitung von TIPS- bzw. NEWS-Informationen der Abhilfesysteme dar. Nachdem die fahrzeuginternen Daten ausgelesen wurden und die standardisierten Symptome vorliegen, startet das System eine Anfrage bei den Systemen TIPS und NEWS. Liegen zu den gegebenen Informationen Abhilfen vor, liefern die Datenbankabfragen die in den ermittelten Abhilfen beinhalteten verdächtigten Fehlerkandidaten. Diese werden in die Kandidatenverrechnung aufgenommen und verarbeitet, so dass im folgenden Schritt ein Prüfschrittbaum unter Berücksichtigung der aus TIPS bzw. NEWS stammenden Fehlerkandidaten erfolgen kann.
Alternativ kann TIPS als reine Informationsquelle dienen. Statt der weiterverarbeitbaren Fehlerkandidaten liefert TIPS dann eine Sammlung an Dokumenten. Diese werden dem Servicetechniker angezeigt bevor er in die systemgeführte Prüfung einsteigt .
Mit Hilfe der gewichteten Fehlerkandidatenliste aus der Kandidatenverrechnung ist im nächsten Schritt der Prüfbaum aufzuspannen. Dieser Schritt läuft automatisch und im Hintergrund. Der Algorithmus greift dabei auf Prüschritt-Primitive zu, die einzelne Prüfungen einsch einschließlich der dabei geprüften Fehlerkandidaten und die für die Prüfung benötigten Informationen, sowie der entstehenden Reparaturkosten beinhalten. Fig. 11 stellt diesen Prozessschritt dar. Der Baum versucht die Fehlersuchzeit sowie die Kosten der Fehlersuche zu minimieren. Hierbei gilt es demnach, einen möglichst flachen Baum aufzuspannen. Ist der Prüfbäum aufgespannt, bekommt der Servicetechniker den ersten Prüfschritt angezeigt und durchläuft geführt die einzelnen Prüfungen. Mit jeder Prüfung werden Fehlerkandidaten als in Ordnung oder nicht in Ordnung geprüft . Damit grenzt der Servicetechniker mit jeder Prüfung den Fehlerraum und damit K weiter ein. Folgt aus einer Prüfung der Ausschluss der geprüften Fehlerkandidaten, so findet eigentlich eine Entlastung statt. Dies soll nach diesem Konzept nicht erfolgen. Der Kandidat soll weiterhin bestehen bleiben, allerdings wird er nun als sporadischer Fehlerkandidat behandelt. Der genaue Hintergrund und der sich ergebene Ablauf wird im folgenden erläutert:
Der Prüfbäum gibt grundsätzlich den effizientesten Weg der Fehlersuche vor. Diese Vorgabe sollte also nach Möglichkeit strikt geführt sein. Will man dem Servicetechniker die Freiheit gewähren, seinen nächsten Prüfschritt aus dem vorgegebenen Prüfbäum selbst auszuwählen, ist ein iterativer Prozess, wie in Fig. 10 anhand der gestrichelten Linie angedeutet, unumgänglich. In Abhängigkeit der zuletzt durchgeführten Prüfung wird der Prüfbäum online korrigiert, so dass zu jedem Zeitpunkt ein optimaler Weg vorgegeben werden kann.
Lokalisierung sporadischer Fehler
Sporadische Fehler sind in der Regel nicht diagnostizierbar, da sie sich nicht reproduzieren lassen. Das wesentliche Problem besteht darin, dass ein Fehler zur Zeit seiner Prüfung nicht vorliegt und dadurch der Kandidat fälschlicherweise entlastet wird. Um dem entgegenzuwirken, verfügen die Daten- Tupel der Fehlerkandidaten über einen zusätzlichen Fehlerstatus, der bei Entlastung von dauerhaft auf sporadisch umgeschaltet wird.
Dementsprechend bleibt der Verdacht zunächst erhalten. Der Kandidat muss auf den sporadischen Verdacht hin (erneut) geprüft werden. Bei einer Leitung bedeutet dies beispielsweise, dass eine Durchgangsprüfung den zuvor als dauerhaft belasteten Fehlerkandidaten Lei tung mit der Fehlerart Unterbrechung entlastet. Hierdurch kommt es zu einem Statuswechsel, so dass der Kandidat Lei tung mit der Fehlerart Unterbrechung und dem Status sporadisch bestehen bleibt. Eine weitere Prüfung für genau diesen Fall, entlastet den Verdacht erst vollständig. Die Prüfung verfolgt das Ziel, den Fehlerkandidaten unter sporadischen Verdacht zu entlasten. Dies könnte beispielsweise bei der Leitung eine Durchgangsprüfung mit dem Hinweis, an der Leitung zusätzlich zu wackeln, sein.
Mit Sicherheit sind derartige Prüfungen mit wesentlich höheren Kosten verbunden, so dass die Prüfungen automatisch zu einem späteren Zeitpunkt herangezogen werden.
Oft kann bereits der Kunde eine Angabe zum Fehlerstatus machen. Die Angabe wird entsprechend bei der Ermittlung der Fehlerkandidaten bei der Symptomverarbeitung berücksichtigt. Die Bedatung steuert diesen Verdacht. Die Prüfschrittdaten- bank ist um Prüfschritte für Kandidatenprüfung unter Verdacht auf einen sporadischen Fehler zu erweitern. Der Algorithmus bei dem Aufspannen des Prüfschrittbaumes koordiniert ihren Einsatz .
Optionale Methoden zur Lokalisierung nicht-reproduzierbarer Fehler
An dieser Stelle sollen optionale Systemerweiterungen vorgeschlagen werden.
In der aus dem Stand der Technik bekannten Werkstattdiagnose spielen insbesondere die sporadischen Fehler eine wesentliche Rolle. Diese Fehler sind im Allgemeinen nur zum Zeitpunkt ihres Vorliegens detektierbar und identifizierbar. Liegt ein solcher Fehler vor muss das Fahrzeug in der Werkstatt verbleiben, um die Beanstandung nachzuvollziehen. Der Kunde verliert das Vertrauen in die Kompetenz der Werkstatt und das Produkt. Wird das Fahrzeug in der Werkstatt gehalten, verur- sacht die Fehlersuche unmittelbar zusätzliche Kosten durch ein Ersatzfahrzeug. Die langfristigen Auswirkungen, durch den Verzicht auf das eigene Fahrzeug des Kunden, sind erst gar nicht überschaubar. Die Fehlersuche erstreckt sich oft über ein Wochenende. Der Kunde hat sein Fahrzeug nicht zur Disposition, während die Werkstatt nicht an der Fehlerlokalisierung arbeitet. Daher sind vor allem Systeme gefragt, die das Geschehen innerhalb des Fahrzeuges verfolgen können. Einen zusätzlichen Reiz haben Systeme, bei denen der Kunde nicht auf sein Fahrzeug verzichten muss, während die Werkstatt versucht, den Fehler zu finden. Folgende optionalen Systemerweiterungen des hier beschriebenen Diagnosesystems stellen ein erhebliches Potential zur Verbesserung der vorbekannten Diagnosesysteme bereit :
• Datenlogger: Unter Einverständnis des Fahrzeughalters sollte ein parametrierbarer Datenlogger eingesetzt werden. Je nach Symptom nimmt der Logger wichtige Daten auf, die zu einem späteren Zeitpunkt zentral oder mit einem speziellen Werkstattsystem analysiert werden. Ein Konverter zur Visualisierung der Daten in der Werkstatt sollte vorhanden sein. Um Speicher zu sparen, kann der Logger als Ringpuffer realisiert werden, der die Daten über ein definiertes Intervall um den Zeitpunkt der Feh- lerdetektion aufzeichnet. Durch den Ringpuffer können auch Daten vor der Fehlermeldung aufgezeichnet werden. Als Trigger eignet sich ein festgelegter Fehlercode oder der Response-on-event-Mechanismus .
• Ferndiagnose: Die Ferndiagnose ist als Ergänzung zum Datenlogger zu betrachten. Grundlage der Ferndiagnose ist eine temporär integrierbare Komponente (Fahrzeug- Interface) , die an der Fahrzeugkommunikation passiv beteiligt ist. Zusätzlich sind weitere Eingänge denkbar, die physikalische Messdaten unmittelbar am Fahrzeug abgreifen. Des Weiteren enthält die Komponente ein GSM- Modem, um die Fahrzeugdaten an ein externes Diagnosegerät oder -team zu übermitteln.
Die Fehlerlokalisierung findet offboard statt, während der Kunde nicht auf sein Fahrzeug verzichten muss. Durch eine Nominalüberwachung kann der Fehler detektiert werden. Alternativ triggern Fahrzeugereignisse den Diagnoseprozess. Letzteres basiert auf einer Verarbeitung regulärer Systembotschaften oder dem Response-on-event Mechanismus, indem das Steuergerät ereignisorientiert reagiert .
Die Kommunikationsaufnähme zum Fahrzeug erfolgt durch die Fahrzeugkomponente oder das externe Diagnosegerät bzw. -Team. Zukünftig kann für die Kommunikation größerer Datenmengen UMTS eingesetzt werden.
Wie bereits erwähnt, kann die Diagnose durch ein kompetentes Team unter Zuhilfenahme des Entwicklers unternommen werden. Für die automatische Diagnose stehen fall- spezifisch verschiedene Verfahren zur Verfügung. Während für statische Fälle regelbasierte oder modellbasierte Verfahren zur Verfügung stehen, übernimmt beispielsweise eine Auswertung von Zustandsautomaten oder die Residuenverarbeitung die Diagnose dynamischer Vorgänge. Eine Auswertung mit Zustandsautomaten basiert auf der Möglichkeit einer Abbildung der Trajektorien von Zustands- größen auf nichtdeterministische oder stochastische Automaten. Liegt eine Diskretisierung des Zustandsraumes vor, verhält sich das System ereignisdiskret. Funktionale Zusammenhänge können in einem Kausalitätsgraphen oder Bayes 'sehen Netzwerk dargestellt und entsprechend ausgewertet werden.
Temporäre Onboard-Diagnose . Eine temporäre Onboard- Diagnose stellt eine weitere optionale Erweiterung für das hier offenbarte Diagnosesystem dar, das einen signifikanten Beitrag zur Fehlerlokalisierung von sporadischen Fehlern leisten kann. Sie wird in das Fahrzeug integriert und übernimmt die Systemauswertung zur Laufzeit mit allen notwendigen Randbedingungen.
Da für eine temporäre Onboard-Diagnose nicht die heutigen Einschränkungen bezüglich der Ressourcen im Embed- ded-Bereich gelten, kann ihr volles Potential ausgeschöpft werden. Größere Kapazitäten der zur Verfügung stehende Speicher- und Rechen-Ressourcen, die mit temporär eingebauten Geräten möglich sind, ermöglichen eine Erweiterung der Wissensbasen sowie den Einsatz modellbasierter Ansätze onboard im Fahrzeug, so dass auch Mehrfachfehler lokalisiert werden können. Stochastische Automaten oder Analysen kausaler Zusammenhänge übernehmen die Diagnose dynamischer oder funktionaler Vorgänge. Das Ergebnis der Onboard-Diagnose kann in der Werkstatt wieder ausgelesen und weiterverarbeitet werden. Alternativ ist eine Kombination der temporären Onboard-Diagnose mit der Ferndiagnose denkbar. Hierbei übernimmt die Onboard-Diagnose die Vorverarbeitung bzw. Vorauswertung im Fahrzeug und kommuniziert die Ergebnisse an eine externe Einheit .

Claims

DaimlerChrysler AGPatentansprüche
Rechnergestütztes Diagnosesystem für technische Vorrichtungen mit einem ablauffähigen Diagnoseprogramm, - das mit einem implementierten Auswertealgorithmus fehlerspezifische technische Systemdaten der zu analysierenden technischen Vorrichtung erfasst, - das mit dem Auswertealgorithmus die erfassten, technischen Systemdaten mit einem rechnerverarbeit- baren Modell der technischen Vorrichtung und mit einer technischen Wissensbasis, in der zu dem rechnerverarbeitbaren Modell regelbasiertes Diagnosewissen über die zu analysierende technische Vorrichtung abgelegt ist, bewertet, interpretiert und zu einer Diagnoseentscheidung gelangt, wobei die Diagnoseentscheidung eine erste Fehlerkandidatenmenge enthält, die angibt welche Teile der technischen Vorrichtung, als fehlerhaft verdächtigt werden, dadurch gekennzeichnet, dass mit einem Mensch-Maschine-Interface beobachtete Fehlersymptome erfasst werden und auf einen aktuellen, modellbasierten Symptombaum abgebildet werden - und dass der Auswertealgorithmus mit einer Symptomverarbeitung und einer zweiten symptombasierten Wissensbasis die Symptome des aktuellen, standardisierten Symptombaums bewertet, interpretiert und eine zweite Fehlerkandidatenmenge ermittelt.
2. Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass mindestens eine der beiden Fehlerkandidatenmengen für die einzelnen Fehlerkandidaten sowohl Belastungsmerkmale als auch Entlastungsmerkmale enthalten.
3. Diagnosesystem nach Anspruch 1 oder 2 , dadurch gekennzeichnet, dass die Fehlersymptome aus einer Kundenbeanstandung ermittelt werden.
4. Diagnosesystem nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der Auswertealgorithmus die erste und die zweite Fehlerkandidatenmenge miteinander verrechnet.
5. Diagnosesystem nach Anspruch 4, dadurch gekennzeichnet, dass bei der Verrechnung von erster und zweiter Fehlerkandidatenmenge diejenigen Fehlerkandidaten ausgesondert werden, die Entlastungsmerkmale enthalten.
6. Diagnosesystem nach Anspruch 4, dadurch gekennzeichnet, dass bei der Verrechnung von erster und zweiter Fehlerkandidatenmenge die Durchschnittsmenge beider Fehlerkandidatenmengen bestimmt wird.
7. Diagnosesystem nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass für die Fehlerkandidaten eine Priorisierung durchgeführt wird.
8. Diagnosesystem nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass zu der ermittelten Fehlerkandidatenmenge ein Prüfschrittbaum aufgespannt wird.
9. Diagnosesystem nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass das Diagnosesystem in seiner Struktur um weitere Auswertealgorithmen und Wissensbasen erweiterbar ist.
10. Diagnosesystem nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet , dass mit einem Abhilfesystem (Tips/News) eine weitere Fehlerkandidatenmenge ermittelt wird.
11. Diagnosesystem nach Anspruch 8, dadurch gekennzeichnet, dass der Prüfschrittbaum aus Prüfschrittprimitiven aufgespannt wird.
12. Diagnosesystem nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass von dem Auswertealgorithmus eine weitere Wissensbasis zur Fahrzeughistorie mit in die Bestimmung der Fehlerkandidatenmenge einbezogen wird.
PCT/EP2005/004816 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 WO2005111752A1 (de)

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
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
DE102004024262.3 2004-05-15

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)

* Cited by examiner, † Cited by third party
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 (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
US8762165B2 (en) 2006-06-14 2014-06-24 Bosch Automotive Service Solutions Llc Optimizing test procedures for a subject under test
US7643916B2 (en) 2006-06-14 2010-01-05 Spx Corporation Vehicle state tracking method and apparatus for diagnostic testing
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
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
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
US8949393B2 (en) * 2007-11-21 2015-02-03 Alcatel Lucent Self-service application for a service management system and method of operation thereof
WO2009097435A1 (en) * 2008-01-29 2009-08-06 Telcordia Technologies, Inc. System and method for automated distributed diagnostics for networks
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
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
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
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
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
EP3127052A1 (de) * 2014-04-01 2017-02-08 Scania CV AB Fehlerverfolgung von fahrzeugen
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
US11190608B2 (en) 2018-03-21 2021-11-30 Cdk Global Llc Systems and methods for an automotive commerce exchange
US11501351B2 (en) * 2018-03-21 2022-11-15 Cdk Global, Llc Servers, systems, and methods for single sign-on of 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 深圳市德塔防爆电动汽车有限公司 一种基于安全树模型的电动车辆安全设计优化方法
DE102019206837A1 (de) * 2019-05-10 2020-11-12 Dürr Systems Ag Analyseverfahren und Vorrichtungen hierzu
EP3966650B1 (de) 2019-05-09 2024-03-06 Dürr Systems AG Verfahren zur kontrolle und nachbehandlung von werkstücken, kontrollanlage und behandlungsanlage
CN113874895A (zh) 2019-05-09 2021-12-31 杜尔系统股份公司 分析方法及用于该分析方法的装置
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 重庆科创职业学院 计算机排障系统
US11983145B2 (en) 2022-08-31 2024-05-14 Cdk Global, Llc Method and system of modifying information on file

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5442555A (en) * 1992-05-18 1995-08-15 Argonne National Laboratory Combined expert system/neural networks method for process fault diagnosis
DE19523483A1 (de) * 1995-06-28 1997-01-02 Daimler Benz Ag Rechnergestützte Fehlerdiagnoseeinrichtung für ein komplexes technisches System
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)

* Cited by examiner, † Cited by third party
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

Patent Citations (4)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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
DE102004024262A1 (de) 2005-12-01
EP1751637A1 (de) 2007-02-14
US20070226540A1 (en) 2007-09-27

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
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
EP0685086B1 (de) Einrichtung zur automatischen erzeugung einer wissensbasis für ein diagnose-expertensystem
EP2146262A1 (de) Verfahren zum Bestimmen fehlerhafter Komponenten in einem System
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 (de) Anwendung einer verteilten diagnosearchitektur in 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
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
EP1960854A1 (de) Diagnoseverfahren und diagnosevorrichtung zur funktionsorientierten diagnose eines systems mit vernetzten komponenten
DE102018212801A1 (de) Diagnose komplexer Systeme
DE10213895A1 (de) Diagnosemodul
DE102020213830A1 (de) Verfahren und System zur Bereitstellung einer Diagnoseinformation

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