WO2006133865A1 - Dynamische priorisierung von prüfschritten in der werkstattdiagnose - Google Patents

Dynamische priorisierung von prüfschritten in der werkstattdiagnose Download PDF

Info

Publication number
WO2006133865A1
WO2006133865A1 PCT/EP2006/005572 EP2006005572W WO2006133865A1 WO 2006133865 A1 WO2006133865 A1 WO 2006133865A1 EP 2006005572 W EP2006005572 W EP 2006005572W WO 2006133865 A1 WO2006133865 A1 WO 2006133865A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
error
diagnostic
computer
candidate
Prior art date
Application number
PCT/EP2006/005572
Other languages
English (en)
French (fr)
Inventor
Martin Konieczny
Harald Renninger
Original Assignee
Daimlerchrysler Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Daimlerchrysler Ag filed Critical Daimlerchrysler Ag
Publication of WO2006133865A1 publication Critical patent/WO2006133865A1/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/0208—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the configuration of the monitoring system
    • G05B23/0216—Human interface functionality, e.g. monitoring system providing help to the user in the selection of tests or in its configuration
    • 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/0221—Preprocessing measurements, e.g. data collection rate adjustment; Standardization of measurements; Time series or signal analysis, e.g. frequency analysis or wavelets; Trustworthiness of measurements; Indexes therefor; Measurements using easily measured parameters to estimate parameters difficult to measure; Virtual sensor creation; De-noising; Sensor fusion; Unconventional preprocessing inherently present in specific fault detection methods like PCA-based methods

Definitions

  • the diagnostic system of the present invention employs a decision-making process based on entropy and cost evaluations of tests, with the aim of being able to suggest optimal tests to the service technician at each time of a diagnostic session.
  • the test domain, the relations between tests and components to be tested can be modeled using a rule-based knowledge base, a mathematical-physical model of system diagnostics or Bayesian networks and compiled into an executable computer program.
  • the focus of this invention lies in the determination of the error candidates and in the construction of the decision function for the test step selection.
  • An example of a system diagnosis is disclosed in the German patent application DE 195 23 483 Al.
  • the characteristic of the system diagnosis is the mapping of the system to be diagnosed into at least one physical-mathematical model that can be implemented and processed with computer assistance.
  • the modeling comprises a structural model and an impact model, which is often referred to as a behavioral model.
  • the structure model depicts the physical relationships of the individual components of the technical system, and the behavioral model maps the functions of the individual components of the system.
  • a knowledge base which is essentially a rule table from If / then conditions, which in turn can be mapped to data tuples, the diagnostic knowledge relevant for the system diagnostics is stored. With the system diagnostics a fault detection and by recourse to the knowledge base a computer-aided troubleshooting can be carried out.
  • System diagnostics has two major disadvantages.
  • the modeling is extremely expensive for larger technical systems, such as a motor vehicle, if all possible causes of faults are to be controlled by the system.
  • Even more difficult to handle in system diagnostics are ambiguous system states, eg if a recorded error code can have several causes that can not be further processed by the system diagnostics due to the lack of sufficient error environment data or insufficient information about the current system state.
  • the system diagnostics then stops at this point without diagnostic result.
  • Another disadvantage of the system diagnosis is its basic unsuitability for the processing of experience of the service technician. Nor can Customer information on defective functions or on intact functions in the diagnostic process.
  • Diagnostic systems of the aforementioned type have the further disadvantage that they very quickly become very complex and the necessary modeling effort, calculation effort and calculation effort for larger technical systems increases exponentially with the number of error possibilities of the individual components of the overall system.
  • all possible checks must be mapped into a static test step tree for diagnostics.
  • the technician must always check the entire modeled system. At no time is the attempt made to identify, identify or even narrow down a component. Only the statistical failure probabilities of system components are considered. Information about actual errors or malfunctions can not be processed by the system.
  • the design of the system assumes that the decomposition can always be done and that the individual components of the decomposition have no influence on the fault condition of the components connected to them. In other words, it is assumed that the decompositions are equivalent in terms of the fault condition of the system. However, this is an assumption that applies only to a few systems, perhaps telephone networks. For most networked systems, component failure also causes malfunction in the rest of the system.
  • This earlier application of the applicant mainly contains an interactively operating diagnostic program, in which the service technician can set a focus for the further, automated troubleshooting by the diagnostic program within a troubleshooting space of the diagnostic program initially identified as potentially defective components or functions identified.
  • the focus can be set by restricting to an error code or by restricting to a function. After setting the focus, a limited focus amount is selected that matches the selected focus of possible error candidates. In this case, the individual error candidates experience - by offsetting different probabilities for the occurrence of an error code, for the probability of failure of a component or a Function and, if necessary, for the presence of an error image -, a weighting.
  • the diagnostic system has the additional possibility of processing error images.
  • Fault images here are combinations of several fault codes that are specific to the failure of a particular component and thus can provide a direct indication of the defective component.
  • the error images can be formed from a combination of active and non-active error codes.
  • the non-active error codes can provide particularly valuable information on non-defective components and thus limit the number of possible error candidates.
  • a new focus can be set by the service technician and thus a new focus set with weighted error candidates can be generated.
  • the object according to the invention arises for setting up a test step sequence for a set of already weighted and identified error candidates which the preselected candidate for the error can be examined as effectively as possible.
  • the solution succeeds mainly with a diagnostic system that generates an error candidate quantity first by means of system queries and by processing the queried system messages or system states with a diagnostic program.
  • the error candidates in this candidate error quantity are already prioritized with regard to error probability.
  • This prioritization can be taken into account when setting up a test step tree and helps to build the most efficient test step tree possible in the respective faulty system state. Basically, the prioritization of the error candidates is not necessary. For example, all error candidates of the candidate error quantity may also have the same error probabilities.
  • the checks that are used to model the relations between the tests to be performed and the error candidates to be checked are used to determine by computer the tests relevant for the checking of the error candidates and to be evaluated by means of a program module for the test step prioritization.
  • the evaluation is carried out with a decision function, which evaluates the individual tests with regard to their information content for the current diagnosis problem in the form of the current candidate error quantity.
  • the decision function in addition to the evaluation of the information content of the individual tests, the decision function also contains a cost evaluation of the individual tests.
  • the two assessments can be used to assess the efficiency of the two be summarized. The efficiency of the test is then determined by the quotient of the information content and the cost of carrying out the individual test.
  • test step prioritization contains the decision function an evaluation and selection of the test steps with regard to the expected costs of further diagnosis, the so-called Expected Costs of Diagnosis.
  • test domain is modeled by a Bayes network.
  • the check domain is modeled using a rule-based knowledge base.
  • the check domain is modeled with a mathematical-physical model of the technical system.
  • the clamping of the test step tree takes place automatically and dynamically.
  • Automatic means that after the check step prioritization, the tests to be performed are displayed to the service technician by the diagnostic system, without the service technician having to search out the checks.
  • Dynamic clamping basically means two aspects.
  • the Test step prioritization dynamically with the number of currently suspected error candidates and second dynamically with the number of tests already performed and proposed.
  • the diagnostic system has a feedback option with which the service technician can enter the result of the tests carried out as evidence in the diagnostic system. After evidence has been entered, the diagnostic system updates the candidate defect quantity if an error candidate was found, and the step prioritization deletes the already used tests.
  • Test step prioritization and diagnostics system can be tracked dynamically to the progress of the diagnostics session. If only one single candidate is found, the search ends and prioritization is unnecessary.
  • the check step prioritization starts with a prioritized list of error candidates, which was determined by a diagnostic system in a diagnostic run as erroneously suspected components and prioritized with regard to their error probabilities.
  • the check step prioritization starts with a unweighted candidate list.
  • This basic stage has the advantage that even commercially available diagnostic systems, such as those discussed in connection with the prior art in FIG. 1, can be used to determine the error candidates. Details of the invention will be explained in more detail below with reference to graphical representations.
  • FIG. 1 A typical workshop diagnostic system of the prior art
  • Fig. 2 is a block diagram of a diagnostic system, as in the earlier German patent application DE
  • FIG. 3 is a schematic diagram of the invention
  • Figure 1 a situation is shown schematically, as it is known today in motor vehicle workshops.
  • a computer-aided diagnostic tester 1 is connected via a standardized diagnostic interface 2 to the communication network 3 for the control units 4 in the motor vehicle.
  • Known diagnostic testers are z.
  • the DAS system from DaimlerChrysler or the BMW DIS system.
  • the control units 4 installed in the motor vehicle are in communication with each other, for example via a data bus.
  • a common data bus in motor vehicles here is the so-called CAN bus (for Control Area Network).
  • Each of the installed control units in the motor vehicle has the ability to self-diagnose in addition to the communication interfaces.
  • error memory As part of the self-diagnosis of the ECUs detected by the diagnostic routine in the ECUs errors in codified form as so-called error codes from the ECU software in specially reserved memory areas, so-called error memory, written. In the schematic representation of FIG. 1, these reserved, non-volatile memory areas are designated FS (for error memory).
  • FS for error memory
  • the standard for the Keyword Protocol 2000 includes two different application options. On the one hand, the standard stipulates that the communication between the diagnostic tester and the control units is effected via a gateway 5, which is eg. B. binds the motor vehicle CAN bus to the diagnostic interface 2, or takes place, as usual, the error memory of the control units via the so-called. K and L lines and read via the normalized diagnostic interface 2 directly into the diagnostic tester and stored can be.
  • a gateway 5 which is eg. B. binds the motor vehicle CAN bus to the diagnostic interface 2, or takes place, as usual, the error memory of the control units via the so-called.
  • K and L lines and read via the normalized diagnostic interface 2 directly into the diagnostic tester and stored can be.
  • FIG. 1 shows the more modern form of access via a CAN bus and thus via a gateway.
  • the invention is of concern only that there is at least one way to be able to read the error memory of the control units with a diagnostic tester.
  • the transmitted contents of the control device memory, in particular error codes and status data of the control devices are further processed in a diagnostic session with an implemented diagnostic program.
  • the diagnostic program also includes the option of manually inputting further information that is important for a diagnosis via a computer workstation as a human-machine interface.
  • FIG. 2 shows a block diagram of the most important program modules and functions of a diagnostic system according to the invention realized with these program modules.
  • the individual program modules are integrated into a higher-level sequence control of the entire diagnostic system. This sequence control takes over the, call of the individual program modules at the respectively necessary time.
  • the diagnostic system processes error codes FC and inputs by a service technician as input variables.
  • the service technician makes his inputs from a VDU workstation 200, which is typically equipped with a screen and a computer keyboard, each connected to the computer system 201 of the diagnostic system. Via a further interface 202, the computer system can be connected to the motor vehicle to be diagnosed. About the OBD socket (On Board Diagnosis), the control units contained in the motor vehicle can be addressed.
  • OBD socket On Board Diagnosis
  • the self-diagnosis routines of the control units can be started and thereby functional tests of the individual control units are started and it can be accessed and read current system state data from the motor vehicle.
  • One possibility of the technical realization was discussed in connection with FIG.
  • the diagnostic program implemented on the computer system is characterized among other things by a modular structure.
  • the programming and the configuration of the diagnostic system are structured.
  • a first program module 210 according to its function called rule table evaluation, retrieved from the motor vehicle data, such as error codes and system status data to the individual components installed in the motor vehicle, read and processed.
  • the further processing includes checking of rule tables stored in a knowledge base 211.
  • the rule tables contain the diagnostic knowledge relevant for the technical system to be diagnosed. This knowledge is stored, for example, in compressed form in data tuples.
  • the data tuples depict the relationships between the information contained in them.
  • a data tuple is stored for each diagnostic rule.
  • Each data tuple consists of a component identifier Ki, an error code FCi, a symptom sympi as an indication of an affected technical function, and a system status Stat.
  • the rule table evaluation then takes place in such a way that all the stored data tuples are looked up in the entirety, which data tuples contain the error code (s) read in and which components Ki and functions Sympi are called in the identified data tuples and thus from the observed one Error FCi may be affected.
  • the component identifications found in this way are recorded and combined into a first quantity of error candidates and stored.
  • These component identifiers Ki indicate which component or also which function of the technical system can be responsible for the observed error code or for the observed error symptom.
  • the result of this first scouring of the knowledge base is a first set of suspicious components that have been identified based on the identification via the error codes FCi.
  • the troubleshooting space formed by the first candidate set is further tensioned.
  • the possible sources of error are now enhanced by the relevant functions that may be involved in the motor vehicle.
  • the rule tables are searched again, this time not according to detected error codes, but according to the possibly already affected by the error codes components Ki.
  • the components that are to be affected are the possibly affected Sympi functions. These two quantities do not have to be identical. Because it is possible that an error code refers to a component that is relevant for several functions.
  • the result of this second pass through the knowledge base is a supplemented candidate list 214, which now also contains possibly faulty functions in addition to the possibly faulty components.
  • Screen workstation 200 performed a query 215 and displayed whether for further processing already detected error codes or the determined possibly affected functions are to be displayed.
  • the service technician is offered the opportunity to set a focus for the further diagnostic procedure.
  • the focus is set by either selecting a displayed error code or a displayed, suspicious function Sympi by means of graphical menu control, and using it for further processing by the diagnostic program. If the focus is set, further data processing is restricted to this focus. This means that not all detected error codes, suspicious candidates or suspicious functions are considered, but only those that fall under the chosen focus.
  • the individual error candidates are subjected to a weighting in a further program module or method step 217.
  • the probabilities of the error codes FCi For the weighting, the probabilities of the error codes FCi, the probability of the occurrence of sympi and possibly the probability of the occurrence of error images must be calculated. For this purpose, probabilities must be provided which indicate with what certainty a defective component or a candidate Ki causes an error code (P (FCiIKj)), a malfunction (P (Sympi
  • the relative error weighting g (Kj) of a component itself is needed. This information is needed to calculate the prioritized or weighted candidate list.
  • the conditional probabilities are easy to estimate. Most of them are set to "1", but sometimes unsafe symptoms or error codes may take on values less than 1.
  • the error weights g (Kj) can be selected from empirical knowledge, for example, between one and one hundred and represent a relative failure parameter.
  • the current field events can also be taken into account via these error weights g (Kj) by calculating these weights by means of offsetting Error frequencies are adapted.
  • All probabilities and error weights are stored in the database of the diagnostic system 218. Appropriately, these can be filed and bedatet together with the component list, the feature or symptom list and the error image list. These lists are created in the construction of a motor vehicle and therefore need only be supplemented by the knowledge of experience with regard to the conditional probabilities and the error weights. Expediently, the data is model-specific. However, cross-product databases can also be created and used. For cross-database databases, however, the possibility of a series-specific selection, e.g. be kept in the form of an upstream master table.
  • G is a normalization quantity and is determined in a preparatory step or by calculation eg as the sum of all weights g (Kj).
  • the a posteriori error probability or priority Prio (Ki) of a component Ki results from the following product:
  • Pr io (Ki) (g (Ki) / G) - fj P (FQ 1 Ki) -] J P (Sympk ⁇ Ki) ⁇ Y [P (FBl ⁇ Ki)
  • This priority is still not standardized and can alternatively be normalized by dividing by the sum of all candidate priorities.
  • the above-discussed diagnostic system which is within the disclosure of the invention described herein, provides a prioritized candidate list, and is the preferred diagnostic system with which test step prioritization can be performed.
  • the inventive system provides a prioritized candidate list, and is the preferred diagnostic system with which test step prioritization can be performed.
  • Test step prioritization with each diagnostic system that provides an error candidate quantity as a result of diagnosis performed.
  • the final step in the workshop diagnosis is component testing or functional testing, with the goal of complete fault isolation for the quickest possible remedy. Until this time, all available information, such as vehicle diagnoses or customer complaints will be evaluated largely automatically.
  • the focus of the inventive test step prioritization described here lies in the creation of an optimized test sequence.
  • the test step prioritization 220 starts from an error candidate quantity whose error candidates have already been identified and named in a preliminary stage. This situation is illustrated by the block diagram of FIG. 3.
  • a non-prioritized candidate defect quantity 330 is determined by a basic version diagnostic system.
  • a weighted candidate list 340 is determined by a diagnostic system.
  • the software module 350 of the check step prioritization 220 for the determined error candidates determines the relevant checks stored in a knowledge base or in a database 360 for checking the individual suspicious candidates. Once all the relevant tests have been determined, the individual tests are evaluated, prioritized and placed in a test step sequence by the test step prioritization with regard to information content and / or costs.
  • the prioritization of the test steps can hereby be tracked recursively and dynamically to the progress of the diagnostic session, in that the tests already performed by the service technician are entered into the system and the used tests are deleted from the test step sequence.
  • the consumption of a proposed check usually leads to a new prioritization of a weighted check step list 370, which is currently updated in each case to the status of the diagnostic session.
  • the diagnostic system in a first stage creates a list of the suspect components, the candidate defect quantity. Now the diagnostics program can select those checks from a test step database that are relevant for checking the suspicious components. That is, those checks that have at least one reference to the suspected components.
  • the amount of all stored in the database checks is PS.
  • the relevant tests are ps element of PS.
  • the basic key question for determining the best test at the current time is according to the invention: how well does the test ps in the current diagnostic problem, which consists of a candidate error rate, help further?
  • a diagnostic program Decision function proposed, which evaluates the relevant tests with regard to their respective information content for the respective diagnostic problem, or which evaluates the relevant tests for the respective diagnostic problem with regard to the respective costs for carrying out the test, or which evaluates the tests relating to efficiency relevant to the respective diagnostic problem, the efficiency is formed by the quotient of information content and costs.
  • the information content of a test step can e.g. from his Entropie Ent determine.
  • Efficiency Eff then is the ratio of the information content of a test step ps to its cost:
  • the entropy of a test step is understood as the following probability sum:
  • the information content of a test step becomes greatest when its entropy becomes greatest.
  • the entropy becomes greatest when a test step has many outputs, ie many possible test results, and when the individual ones Test results have a possible uncertain outcome. This corresponds to the fact that with this examination I gain the most information, which at the same time checks as many error candidates as possible and of which I least know how the examination ends. Conversely, the exam has the lowest information content, which has only a few outputs and of which I know the result with great certainty already.
  • the decision step for the check step selection is formed by the expected cost of the test steps remaining after the selected check step for the respective remainder of the prospective diagnostic session.
  • This decision function also includes the entropy criterion, which, however, is complemented by a refined and extended cost consideration and cost estimate.
  • the refined and expanded cost estimate calculates, at each current test step, the expected cost of the remaining test, i. which costs are still to be expected, after which a previous test has already been carried out.
  • the designation of the decision function as ECD (Extended Cost of Diagnosis) is based on the term ECR, the Extended Cost of Repair, which is occasionally used in the scientific literature.
  • j is a run index and n is the number of tests remaining after the current test step ps.
  • the estimated cost EstCosts consists of the entropy of the remaining diagnostic problem multiplied by the average cost of testing AvCosts.
  • the latter are the arithmetic mean of the cost of all remaining exams.
  • the respective upcoming test step to be selected is then selected from the possible test steps by selecting in each case that test step which minimizes the expected cost of diagnosis of the respectively remaining diagnostic session.
  • Probabilities p (ps) and the variables derived therefrom of the respectively relevant test steps ps are derived from the Prioritization of the error candidate list is calculated.
  • the relevant test steps are determined for the determined error candidates Ki.
  • the test step ps simultaneously checks two candidates K1 and K2, the test step having the result "not OK” (NOK) if one of the two candidates proves to be faulty and has the result "OK” if both Candidates deliver the test result without errors.
  • the probable outcome of the relevant test steps then results from the error candidate probabilities as follows:
  • Another criterion for a check step prioritization is the cost of a test step to be performed. These costs are known as empirical values e.g. known as so-called labor values, and are assigned during the creation of the test step database and assigned to the individual test steps. Thereby, the decision step function for the check step prioritization may be refined from an entropy to an efficiency selection or a cost estimate according to the expected cost of diagnosis.
  • the decision function for the check step prioritization of the diagnostic system is then either one
  • Test step prioritization based on the information content of the individual relevant test step the test step with the highest information content receives the highest priority, or the decision function prioritizes the individual test steps based on the efficiency defined above, the test step giving the highest priority having the highest efficiency, or a cost estimate corresponding to the expected costs of Diagnosis used.
  • test step sequence can be set up automatically by computer calculations and computer selection.
  • the service technician can be proposed a test step sequence and displayed on a display of a diagnostic system, which begins with the highest priority test step and the subsequent test steps with decreasing prioritization followed.
  • the process flow for a base system with test step prioritization is shown in the block diagram of FIG.
  • the relevant diagnostic steps are determined by the diagnostic program supplemented according to the invention in a subsequent method step 420 and evaluated and prioritized eg with the aforementioned evaluation scheme with regard to efficiency, information content or cost estimate.
  • the service technician or the fitter can select from the displayed checking steps a checking step, for example by menu control, and perform this on the motor vehicle.
  • the result of the test step entered into the diagnostic system and carried out with the newly gained knowledge of a recalculation of the weights of the suspect candidate.
  • the recalculation leads in particular to the deletion of all error candidates already tested and found to be in order from the list of error candidates.
  • the released weights grow in this case the not yet tested error candidate.
  • the test step prioritization is also recalculated and performed, so that the procedure for the check step prioritization is recursive, with the aim as quickly as possible to obtain an error candidate with a probability of error close to 100%. Illustrated in method step 450 of the block diagram.
  • a problem with the check step prioritization may be the more accurate determination of the information content of a check step, if one wants to apply this information content to the current diagnostic session.
  • the above-described uniform distribution of the test outputs is only a first approximation, which, however, on closer inspection may vary with the current diagnostic problem. In particular, already performed tests and the knowledge gained from them can increase or decrease the information content and the value of tests that have not yet been carried out. If you want to adapt the information content of a test step to the progress of the diagnostic session, you need a flexible calculation tool that is able to deal with probabilities. Probability networks and in particular so-called Bayes networks are suitable here. Bayes networks have been used successfully in the fields of fault diagnosis, decision support, reliability analyzes, risk assessment, etc.
  • the Bayes networks serve Here, the representation of relationships and sizes that may be subject to uncertainties or are known only with probability.
  • the so-called propagation methods offer the opportunity to process new information, such as exam results, consistently and thereby calculate the impact on other variables.
  • the Bayes network now serves to represent the relations between testing and tested components and to calculate more accurately the probabilities required for the test step prioritizations and to adapt them to the progress of the diagnostic session.
  • Error candidate list is set up a diagnostic node that contains a state for each suspicious component with a probability that corresponds to the weighting of the error candidate. Now those checks from the check step database can be selected which are relevant, ie which check the suspicious components. The selected test steps are prioritized and selected with one of the decision functions. A test step is still available if it has not already been performed, or if the test output is not already certain. For the test tree construction then both output options of the test, component in order or component not in order, must be present. Then, all relevant unused exams are recursively continued. Such a method is called myoptic or short-sighted, since only the next step is optimized.
  • test tree If the test tree is spanned, the results of the test steps that have been carried out can be entered as evidence in the Bayes network as evidence, and the effect on the remaining components can be calculated and to the remaining components again a test tree are spanned, which selects the most prioritized test steps with the previously described myoptischen method.
  • test step tree which is graphically displayed to the service technician.
  • a graphic representation of such a test step tree is shown in FIG.
  • the states of the determined error candidates are in the form of weights. These are the candidates Kl, K2, K3, K4, K5.
  • the best test step PS1 is selected for the present diagnostic problem.
  • the exam result is reflected back.
  • OK candidate Kl is in order
  • test step PS4 for checking the component K4.
  • PS4 N0K
  • component K4 is identified as faulty. If the check with test step PS4 reveals that component K4 is OK, PS2 continues with the next best test step, which checks component K2 and identifies it at test output Not OK K2. If the test result is OK, it is continued with the best remaining test step. In the example chosen, this is the test step PS3 for checking the component K3.
  • the test result is not so important, because in any case, the last remaining, suspect component K5 must be examined. As a rule, a test is still due for this last review, but this is no longer shown in FIG. It may also be that a restart of the diagnostic system after the Repairs performed the components Kl and K4 shows that so that the error candidate K2, K3, K5 are no longer suspected.
  • Realistic testing problems can include around 50 suspicious components. Each component has at least one individual test. In addition, there are functional tests that cover more than one component. Thus, the number of tests is generally greater than the number of components.
  • the branches of a test step tree are balanced according to their entropy and cost.
  • the error probability and thus the weighting in the candidate error quantity grows to a few mostly one component. Namely, the error probabilities of all of the components already tested in the correct order become zero and enter into the diagnostic program as a check result, so that as the diagnostic candidate progresses and the update of the weighted candidate error quantity by recursive recalculation by the diagnostic program becomes more acute, the diagnostic focus becomes ever sharper.
  • the information content or efficiency of these composite checks is usually very high, as they examine multiple components and therefore provide a large information gain.
  • the composite checks are therefore among the highly prioritized checking steps for an error candidate quantity.
  • the diagnostic session In particular, at the customer meeting in the vehicle acceptance, a current cost estimate for each remaining diagnostic session are determined. For this purpose, the complete test step tree is determined for the error candidate quantity and the costs of the determined test steps are summed up. This cost sum then sets an upper limit on the costs that may possibly be expected in the present diagnosis problem.
  • the service technician is offered a complete test step tree by the diagnostic system in which the individual test steps with regard to efficiency, information content or expected costs of diagnosis are prioritized. Ultimately, it is up to the service technician to decide in which order he performs which test step. The service technician does not have to start with the highest prioritized check of the test step tree.
  • the repairs carried out can be logged with the diagnostic system. This protocol can then be used to suggest tests or test steps to ensure that the installed components or the repair are rechecked to ensure that the repair has been successful and no new faults have been incorporated.
  • the logging function can continuously log the current status of the vehicle in the repair workshop. This can be determined continuously, which components of the motor vehicle are just removed.
  • the dynamic costs of the diagnostic session also depend on the current build state of the vehicle, so that the protocol function can also be used for cost estimation.
  • the tracking of the Verbausches of the vehicle in the Repair succeeds in logging which test steps have already been performed with which test exit.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Human Computer Interaction (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

Die Erfindung betrifft ein Diagnosesystem, das zunächst durch Systemabfragen und durch Verarbeitung der abgefragten Systemmeldungen oder Systemzustände mit einem Diagnoseprogramm eine Fehlerkandidatenmenge erzeugt. Die Fehlerkandidaten in dieser Fehlerkandidatenmenge sind vorzugsweise bereits hinsichtlich Fehlerwahrscheinlichkeit priorisiert. Diese Priorisierung kann beim Aufbau eines Prüfschrittbaumes berücksichtigt werden und hilft in dem jeweiligen fehlerhaften Systemzustand einen möglichst effizienten Prüfschrittbaum aufzubauen. Grundsätzlich ist die Priorisierung der Fehlerkandidaten jedoch nicht notwendig. Es können zum Beispiel auch alle Fehlerkandidaten der Fehlerkandidatenmenge die gleiche Fehlerwahrscheinlichkeiten aufweisen. Zu den ermittelten Fehlerkandidaten werden über die Prüfdomäne, in der die Relationen zwischen durchzuführenden Prüfungen und zu überprüfenden Fehlerkandidaten modelliert ist, die für die Überprüfung der Fehlerkandidaten relevanten Prüfungen per Computer ermittelt und mittels eines Programmmoduls für die Prüfschrittpriorisierung einer Bewertung unterzogen. Die Bewertung erfolgt hierbei mit einer Entscheidungsfunktion, die die einzelnen Prüfungen hinsichtlich ihres Informationsgehaltes für das aktuelle Diagnoseproblem in Form der aktuellen Fehlerkandidatenmenge bewertet.

Description

Dynamische Priorisierung von Prüfschritten in der
Werkstattdiagnose
Werkstattdiagnose ist ein wichtiges Element im Lebenszyklus eines Fahrzeugs. Der Fahrzeugkunde erwartet eine schnelle und kostengünstige Abhilfe im Falle eines Defekts. Der Servicetechniker in der Werkstatt muss bei modernen Fahrzeugen bei dieser Aufgabe unterstützt werden. Dabei ist es nur noch mit Computerunterstützung möglich, die große Menge an anfallenden Informationen zu verarbeiten und den Prüfablauf effizient zu gestalten. Darüber hinaus muss ein Diagnosesystem echtzeitfähig und aus Entwicklungssicht handhabbar und pflegbar sein. Das erfindungsgemäße Diagnosesystem arbeitet mit einem Entscheidungsverfahren basierend auf Entropie- und Kostenbewertungen von Prüfungen, mit dem Ziel dem Servicetechniker zu jedem Zeitpunkt einer Diagnosesitzung optimale Prüfungen vorschlagen zu können. Die Prüfdomäne, die Relationen zwischen Prüfungen und zu prüfenden Komponenten kann mit einer regelbasierten Wissensbasis, einem mathematisch physikalischen Modell der Systemdiagnose oder mit Bayes Netzen modelliert werden und in ein ablauffähiges Computerprogramm compiliert werden. Der Schwerpunkt dieser Erfindung liegt hierbei bei der Ermittlung der Fehlerkandidaten und in der Konstruktion der Entscheidungsfunktion zur PrüfSchrittauswahl . Ein Beispiel für eine Systemdiagnose ist in der deutschen Patentanmeldung DE 195 23 483 Al offenbart. Kennzeichen der Systemdiagnose ist das Abbilden des zu diagnostizierenden Systems in mindestens ein physikalisch-mathematisches Modell, das rechnergestützt implementiert und verarbeitet werden kann. In der DE 195 23 483 Al umfasst die Modellbildung ein Strukturmodell und ein Wirkungsmodell, das oft auch als Verhaltensmodell bezeichnet wird. 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 Systems abgebildet. In einer Wissensbasis, die im Wesentlichen eine Regeltabelle aus Wenn/dann Konditionen, die sich wiederum auf Datentupel abbilden lassen, ist, ist das für die Systemdiagnose relevante Diagnosewissen abgespeichert. Mit der Systemdiagnose kann eine Fehlererkennung und durch Rückgriff auf die Wissensbasis eine rechnergestützte Fehlersuche durchgeführt werden.
Die Systemdiagnose hat zwei entscheidende Nachteile. Die Modellbildung ist für größere technische Systeme, wie z.B. ein Kraftfahrzeug äußerst aufwendig, wenn alle möglichen Fehlerursachen von dem System beherrscht werden sollen. Noch schwieriger zu handhaben sind in der Systemdiagnose mehrdeutige Systemzustände, wenn z.B. ein aufgenommener Fehlercode mehrere Ursachen haben kann, die mangels ausreichender Fehlerumgebungsdaten oder mangels ausreichender Informationen über den aktuellen Systemzustand, von der Systemdiagnose nicht weiter verarbeitet werden können. Die Systemdiagnose bricht dann an dieser Stelle ohne Diagnoseergebnis ab. Ein weiterer Nachteil der Systemdiagnose ist ihre prinzipielle Nichteignung für die Verarbeitung von Erfahrungswissen des Servicetechnikers. Ebenso wenig können Kundenangaben zu defekten Funktionen oder zu intakten Funktionen in den Diagnoseprozess einfließen.
Diagnosesysteme der vorgenannten Art haben den weiteren Nachteil, dass sie sehr schnell sehr komplex werden und der notwendige Modellierungsaufwand, Bedatungsaufwand und Berechnungsaufwand für größere technische Systeme exponentiell mit der Anzahl der Fehlermöglichkeiten der einzelnen Komponenten des Gesamtsystems zunimmt. Außerdem müssen für die Diagnose alle möglichen Prüfungen in einen statischen Prüfschrittbaum abgebildet werden. In der Realität ergibt sich bei Systemen mit mehreren von einander abhängigen Komponenten eine Unmenge von Möglichkeiten, in welcher Reihenfolge einzelne Teilprüfungen von einzelnen Komponenten durchgeführt werden können. Bei 5 Komponenten ergeben sich bereits theoretisch 5 Fakultät unterschiedliche Prüfabläufe, die alle durch einen statischen Prüfbaum abgebildet werden müssten. Die Effizienz der Diagnoseverfahren nimmt daher mit Anzahl der Fehlermöglichkeiten drastisch ab.
Man hat deshalb nach effizienteren Möglichkeiten gesucht, ein Diagnosesystem aufzubauen.
Eine Möglichkeit den Diagnoseablauf zu verbessern ist in der europäischen Patentschrift EP 1 069 487 Bl beschrieben. Parallel zum Reparaturfortschritt kann von einem Servicetechniker an entscheidenden Stellen des Prüfschrittbaumes gesichertes Wissen, so genannte Evidenz, abgefragt werden und in das Diagnosesystem eingerechnet werden. Damit müssen nicht mehr alle Fehlermöglichkeiten und Prüfmöglichkeiten berechnet werden. Das Diagnoseverfahren kann umso effizienter werden je mehr Abfragen an geeigneter Stelle des Diagnoseablaufs systemseitig vorgesehen sind. Die Eingabe des evidenten Wissens erfolgt über eine Benutzer Schnittstelle, die durch ein Display und ein Eingabemenü gebildet wird.
Wünschenswert für die Fehlersuche mit zukünftigen Diagnosesystemen in Werkstätten ist die Kosteneffizienz der durchzuführenden Prüfungen stärker zu berücksichtigen. Ein schneller und effizienter Prüfungsablauf ist somit eine wünschenswerte Vorgabe an diese zukünftigen Diagnosesysteme.
Man hat deshalb z.B. in der europäischen Patentschrift EP 0410632 Bl vorgeschlagen die Prüfungskosten bereits bei der Erstellung der Wissensbasis für das Diagnosesystem zu berücksichtigen. Es wird vorgeschlagen, zweistufig vorzugehen. Indem mit einem ersten modellbasierten Regelsatz das zu diagnostizierende technische System in eine mögliche erste Zerlegung aufgeteilt wird und für diese erste Zerlegung die Kostenberechnung einer Überprüfung durchgeführt wird. Dann werden weitere mögliche Zerlegungen des Systems berechnet und für jede Zerlegung wieder eine Kostenrechnung für eine Überprüfung des Systems durchgeführt. Die wirtschaftlichste Überprüfung des Systems soll wohl diejenige sein, dessen Zerlegung die geringsten Kosten ergibt. Liegt die günstigste Zerlegung des Systems fest, liegt zumindest prinzipiell auch ein Vorschlag für die Überprüfung des Systems, wenn man so will ein Prüfplan, fest.
Das vorgenannte System hat allerdings aus Sicht der hier vorliegenden Erfindung mehrere gravierende Nachteile: - Es müssen stets mehrere mögliche Zerlegungen des technischen Systems berechnet und bewertet werden. Damit wird eine Feingliederung des technischen System oft nicht beherrschbar, da hier die Zerlegungsmöglichkeiten und insbesondere die damit verbundenen Kosten der Überprüfung sehr schnell sehr rechenintensiv werden und die Gefahr besteht das die Berechnungen NP-hard, also länger dauern als die Lebenserwatung eines Menschen ist, werden .
Gelingt es eine bevorzugte Zerlegung mit den geringsten Prüfkosten zu berechnen, so muss der Techniker trotzdem stets das gesamte modellierte System überprüfen. Es wird zu keiner Zeit der Versuch gemacht einen Fehler zu bestimmen, zu identifizieren oder gar auf eine Komponente einzugrenzen. Es werden lediglich die statistischen Ausfallwahrscheinlichkeiten von Systembestandteilen berücksichtigt. Informationen über tatsächlich vorliegende Fehler oder Fehlfunktionen können mit dem System nicht verarbeitet werden. Das Design des Systems geht davon aus, dass die Zerlegung stets so erfolgen kann und auch erfolgt, dass die einzelnen Komponenten der Zerlegung keinen Einfluss auf den Fehlerzustand der mit Ihnen verbundenen Komponenten hätte. Anders gesagt, es wird vorausgesetzt dass die Zerlegungen hinsichtlich des Fehlerzustandes des Systems gleichwertig sind. Dies ist jedoch eine Annahme, die nur auf wenige Systeme, vielleicht Telefonnetze, zutrifft. Bei den meisten vernetzten Systemen verursacht der Ausfall einer Komponente auch Fehlfunktionen in den übrigen Bestandteilen des Systems. Bei Systemen, die nicht nur statistische Ausfallwahrscheinlichkeiten berücksichtigen, sondern auch festgestellte Fehlermeldungen verarbeiten, ist der Ansatz der gleichwertigen Zerlegungen nicht kompatibel. Es bleibt völlig unklar, welche Systeme sich überhaupt sinnvoll in verschiedene Zerlegungen zerlegen lassen. Bei fast allen, vernetzten Systemen gibt es nur eine tatsächliche Vernetzung, bei der auch der Fehler gefunden werden muss und es bleibt unklar inwieweit eine rechnerisch mögliche, abweichende Zerlegung hier eine belastbare Aussage liefern kann, die einen nachvollziehbaren Vorteil oder Erkenntnisgewinn liefert.
Bei allen möglichen Zerlegungen bleibt die Fehlersuche und Fehlerlokalisation dem Servicetechniker überlassen und der Servicetechniker erhält auch keine Hinweise, wie er die Fehlersuche am effektivsten durchführt. Kostenabschätzungen sind keine Effektivitätsaussagen.
In einer älteren, nachveröffentlichten Anmeldung der Anmelderin beim Deutschen Patent und Markenamt mit dem amtlichen Aktenzeichen DE 102005015664.9 ist ein selbstständiges Diagnosesystem beschrieben, das mit der hier beschriebenen Erfindung weiterentwickelt wird. Der Offenbarungsgehalt dieser älteren Anmeldung wird ausdrücklich per Referenz mit seinem ganzen Umfang in den Offenbarungsgehalt der hier beschriebenen Erfindung integriert. Diese ältere Anmeldung der Anmelderin enthält hauptsächlich ein interaktiv arbeitendes Diagnoseprogramm, bei dem der Servicetechniker, innerhalb eines von dem Diagnoseprogramm zunächst aufgespannten Fehlersuchraumes der als möglicherweise defekt identifizierten Komponenten oder Funktionen, einen Fokus für die weitere, automatisierte Fehlersuche durch das Diagnoseprogramm setzen kann. Das Setzen des Fokus kann hierbei durch Einschränkung auf einen Fehlercode oder durch Einschränkung auf eine Funktion erfolgen. Nach Setzen des Fokus wird eine eingeschränkte Fokusmenge, der zu dem gewählten Fokus möglichen Fehlerkandidaten ausgewählt. Die einzelnen Fehlerkandidaten erfahren hierbei, - durch Verrechnung von verschiedenen Wahrscheinlichkeiten für das Auftreten eines Fehlercodes, für die Ausfallwahrscheinlichkeit einer Komponente oder einer Funktion und gegebenenfalls für das Vorliegen eines Fehlerbildes - , eine Gewichtung.
In einer vorteilhaften Ausführungsform des älteren Diagnosesystems verfügt das Diagnosesystem über die zusätzliche Möglichkeit Fehlerbilder zu verarbeiten. Fehlerbilder sind hierbei Kombinationen mehrerer Fehlercodes, die spezifisch sind für den Ausfall einer bestimmten Komponente und so einen direkten Hinweis auf die defekte Komponente liefern können. Die Fehlerbilder können hierbei aus einer Kombination von aktiven und nicht aktiven Fehlercodes gebildet werden. Hierbei können die nicht aktiven Fehlercodes besonders wertvolle Hinweise auf nicht defekte Komponenten liefern und so die Menge der möglichen Fehlerkandidaten einschränken.
In einer weiteren vorteilhaften Ausführungsform des älteren Diagnosesystem kann, wenn die Überprüfung der Fehlerkandidaten in der Fokusmenge ergeben hat, dass keine der untersuchten Komponenten defekt war, ein neuer Fokus durch den Servicetechniker gesetzt werden und damit eine neue Fokusmenge mit gewichteten Fehlerkandidaten erzeugt werden.
Zusammenfassend lässt sich somit festhalten, dass es zwar Diagnosesysteme mit Fehlerlokalisation gibt, und dass es Überlegungen zu kostenoptimierten Prüfabläufen bei Diagnosesystemen ohne Fehlerlokalisation gibt. Jedoch gibt es bisher keine Diagnosesysteme die den Servicetechniker dahingehend unterstützen, die notwendigen Überprüfungen nach dem Gesichtpunkt der Effektivität durchzuführen.
Es stellt sich somit die erfindungsgemäße Aufgabe für eine Menge bereits gewichteter und identifizierter Fehlerkandidaten eine Prüfschrittabfolge aufzustellen, mit der die vorausgewählten Fehlerkandidaten möglichst effektiv untersucht werden können.
Die Lösung gelingt hauptsächlich mit einem Diagnosesystem, das zunächst durch Systemabfragen und durch Verarbeitung der abgefragten Systemmeldungen oder Systemzustände mit einem Diagnoseprogramm eine Fehlerkandidatenmenge erzeugt. Die Fehlerkandidaten in dieser Fehlerkandidatenmenge sind bereits hinsichtlich Fehlerwahrscheinlichkeit priorisiert. Diese Priorisierung kann beim Aufbau eines Prüfschrittbaumes berücksichtigt werden und hilft in dem jeweiligen fehlerhaften Systemzustand einen möglichst effizienten Prüfschrittbaum aufzubauen. Grundsätzlich ist die Priorisierung der Fehlerkandidaten jedoch nicht notwendig. Es können zum Beispiel auch alle Fehlerkandidaten der Fehlerkandidatenmenge die gleiche Fehlerwahrscheinlichkeiten aufweisen. Zu den ermittelten Fehlerkandidaten werden über die Prüfdomäne, in der die Relationen zwischen durchzuführenden Prüfungen und zu überprüfenden Fehlerkandidaten modelliert ist, die für die Überprüfung der Fehlerkandidaten relevanten Prüfungen per Computer ermittelt und mittels eines Programmmoduls für die Prüfschrittpriorisierung einer Bewertung unterzogen. Die Bewertung erfolgt hierbei mit einer Entscheidungsfunktion, die die einzelnen Prüfungen hinsichtlich ihres Informationsgehaltes für das aktuelle Diagnoseproblem in Form der aktuellen Fehlerkandidatenmenge bewertet.
In einer vorteilhaften Ausführungsform der Entscheidungsfunktion enthält die Entscheidungsfunktion zusätzlich zur Bewertung des Informationsgehalts der einzelnen Prüfungen noch eine Kostenbewertung der einzelnen Prüfungen. Vorteilhafterweise können die beiden Bewertungen zu einer Bewertung hinsichtlich Effizienz der durchzuführenden Prüfung zusammengefasst sein. Die Effizienz der Prüfung bestimmt sich dann aus dem Quotienten aus Informationsgehalt und der Kosten für die Durchführung der einzelnen Prüfung.
In einer bevorzugten Ausführungsform der
Entscheidungsfunktion und damit der Prüfschrittpriorisierung enthält die Entscheidungsfunktion eine Bewertung und Auswahl der Prüfschritte hinsichtlich der noch zu erwartenden Kosten der weiteren Diagnose, den hier sogenannten Expected Costs of Diagnosis .
In einer weiteren Ausführungsform der erfindungsgemäßen Prüfschrittpriorisierung wird die Prüfdomäne durch ein Bayes Netz modelliert.
In einer anderen Ausführungsform der erfindungsgemäßen Prüfschrittpriorisierung wird die Prüfdomäne mit einer regelbasierten Wissensbasis modelliert.
In einer weiteren Ausführungsform der erfindungsgemäßen Prüfschrittpriorisierung wird die Prüfdomäne mit einem mathematisch physikalischen Modell des technischen Systems modelliert .
In einer weiteren vorteilhaften Ausführungsform der erfindungsgemäßen Prüfschrittpriorisierung erfolgt das Aufspannen des Prüfschrittbaumes automatisch und dynamisch. Automatisch bedeutet hierbei, dass nach der Prüfschrittpriorisierung die durchzuführenden Prüfungen dem Servicetechniker von dem Diagnosesystem angezeigt werden, ohne dass der Servicetechniker die Prüfungen noch heraussuchen müsste. Das dynamische Aufspannen meint hauptsächlich zwei Aspekte. Zum anderen erfolgt die Prüfschrittpriorisierung dynamisch mit der Anzahl der aktuell verdächtigen Fehlerkandidaten und zum zweiten dynamisch mit der Anzahl der bereits durchgeführten und vorgeschlagenen Prüfungen. Hierzu hat das Diagnosesystem eine Feedbackmöglichkeit, mit der der Servicetechniker das Ergebnis der durchgeführten Prüfungen als Evidenz in das Diagnosesystem eingeben kann. Nach Eingabe einer Evidenz wird vom Diagnosesystem die Fehlerkandidatenmenge aktualisiert, falls ein Fehlerkandidat gefunden wurde, und von der Prüfschrittpriorisierung werden die bereits verbrauchten Prüfungen gestrichen. Prüfschrittpriorisierung und Diagnosesystem können so dynamisch an den Fortschritt der Diagnosesitzung nachgeführt werden. Wird nur ein einziger Fehlerkandidat gefunden, endet die Suche und eine Priorisierung erübrigt sich.
In einer vorteilhaften Ausführungsform der erfindungsgemäßen Prüfschrittpriorisierung, startet die Prüfschrittpriorisierung mit einer priorisierten Fehlerkandidatenliste, die von einem Diagnosesystem bei einem Diagnoselauf als fehlerhaft verdächtigte Komponenten ermittelt und hinsichtlich ihrer Fehlerwahrscheinlichkeiten priorisiert wurde.
In einer weniger bevorzugten Basisstufe der erfindungsgemäßen Prüfschrittpriorisierung, startet die Prüfschrittpriorisierung mit einer ungewichteten Fehlerkandidatenlist. Diese Basisstufe hat den Vorteil, dass auch handelsübliche Diagnosesysteme, wie sie z.B. im Zusammenhang mit dem vorbekannten Stand der Technik in Fig. 1 diskutiert wurden, für die Ermittlung der Fehlerkandidaten eingesetzt werden können. Im Folgenden werden Einzelheiten der Erfindung an Hand von graphischen Darstellungen näher erläutert.
Dabei zeigen:
Fig. 1 Ein typisches Werkstattdiagnosesystem aus dem Stand der Technik; Fig. 2 Ein Blockschaltbild eines Diagnosesystems, wie es in der älteren, deutschen Patentanmeldung DE
102005015664.9 beschrieben ist, und das hier als bevorzugtes Diagnosesystem mit der
Prüfschrittpriorisierung weiterentwickelt wird; Fig. 3 Eine Prinzipskizze der erfindungsgemäßen
Prüfschrittpriorisierung; Fig. 4 Ein Basisverfahren für die erfindungsgemäße
Prüfschrittpriorisierung; Fig. 5 Einen Prüfschrittbaum der erfindungsgemäßen
Prüfschrittpriorisierung;
In Figur 1 ist eine Situation schematisch dargestellt, wie sie heute in Kraftfahrzeugwerkstätten bekannt ist. Für die Diagnose eines Kraftfahrzeuges wird ein rechnergestützter Diagnosetester 1 über eine genormte Diagnoseschnittstelle 2 an das Kommunikationsnetzwerk 3 für die Steuergeräte 4 im Kraftfahrzeug angeschlossen. Bekannte Diagnosetester sind z. B. das System DAS von DaimlerChrysler oder das System BMW- DIS. Die im Kraftfahrzeug verbauten Steuergeräte 4 sind beispielsweise über einen Datenbus miteinander in Kommunikationsverbindung. Ein verbreiteter Datenbus in Kraftfahrzeugen ist hierbei der sog. CAN-Bus (für Control Area Network) . Jedes der verbauten Steuergeräte im Kraftfahrzeug verfügt neben den Kommunikationsschnittstellen über die Fähigkeit zur Eigendiagnose. Im Rahmen der Eigendiagnose der Steuergeräte werden mit Hilfe der Diagnoseroutine in den Steuergeräten festgestellte Fehler in kodifizierter Form als sog. Fehlercodes von der Steuergeräte- Software in speziell reservierte Speicherbereiche, sog. Fehlerspeicher, geschrieben. In der schematischen Darstellung der Figur 1 sind diese reservierten, nicht flüchtigen Speicherbereiche als FS (für Fehler-Speicher) bezeichnet. Für die Kommunikation und für den Datenaustausch zwischen einem Diagnosetester und den im Kraftfahrzeug verbauten Steuergeräten hat sich ein Standard etabliert, der unter dem Namen Keyword-Protokoll 2000 bekannt ist und dessen Spezifizierung und Normierung sich in der ISO-Norm 14 230-3 wiederfindet. Mit den im Keyword-Protokoll 2000 verabredeten Steuerbefehlen und Datenformaten ist es möglich, über die Diagnoseschnittstelle die kodifizierten Inhalte der Fehlerspeicher der einzelnen Steuergeräte mit Hilfe des Diagnosetesters auszulesen und in das Rechensystem des Diagnosetesters zu übertragen. Die Norm zu dem Keyword- Protokoll 2000 umfasst hierbei zwei verschiedene Applikationsmöglichkeiten. Zum einen sieht die Norm vor, dass die Kommunikation zwischen Diagnosetester und Steuergeräte über ein Gateway 5, das z. B. den Kraftfahrzeug-CAN-Bus an die Diagnoseschnittstelle 2 anbindet, erfolgt oder aber, dass wie früher üblich, die Fehlerspeicher der Steuergeräte über die sog. K- und L-Leitungen und über die normierte Diagnoseschnittstelle 2 direkt in den Diagnosetester ausgelesen und abgelegt werden können. In der schematischen Darstellung der Figur 1 ist die modernere Form des Zugriffs über einen CAN-Bus und damit über ein Gateway dargestellt. Für die Erfindung von Belang ist lediglich, dass es mindestens eine Möglichkeit gibt, die Fehlerspeicher der Steuergeräte mit einem Diagnosetester auslesen zu können. Im Diagnosetester werden die übertragenen Inhalte der Steuergerätespeicher insbesondere Fehlercodes und Zustandsdaten der Steuergeräte mit einem implementierten Diagnoseprogramm in einer Diagnosesitzung weiterverarbeitet. Das Diagnoseprogramm umfasst weiterhin die Möglichkeit über einen Bildschirmarbeitsplatz als Mensch-Maschine- Schnittstelle manuell weitere Informationen, die für eine Diagnose wichtig sind einzugeben.
Fig. 2 zeigt als Blockschaltbild die wichtigsten Programmmodule und mit diesen Programmmodulen realisierten Funktionen eines erfindungsgemäßen Diagnosesystems. Die einzelnen Programmmodule sind hierbei in eine übergeordnete Ablaufsteuerung des gesamten Diagnosesystems integriert. Diese Ablaufsteuerung übernimmt den, Aufruf der einzelnen Programmmodule zum jeweils notwendigen Zeitpunkt. Als Eingangsgrößen werden von dem Diagnosesystem Fehlercodes FC und Eingaben durch einen Servicetechniker verarbeitet. Der Service Techniker macht seine Eingaben von einem Bildschirmarbeitsplatz 200, der typischer Weise mit einem Bildschirm und einer Computertastatur ausgestattet ist, die jeweils an das Computersystem 201 des Diagnosesystems angeschlossen sind. Über eine weitere Schnittstelle 202 ist das Computersystem an das zu diagnostizierende Kraftfahrzeug anschließbar. Über die OBD Steckdose (On Board Diagnosis) können die im Kraftfahrzeug enthaltenden Steuergeräte angesprochen werden. Es können dadurch die Fehlerspeicher der Steuergeräte ausgelesen werden, es können die Eigendiagnoseroutinen der Steuergeräte gestartet werden und dadurch Funktionstests der einzelnen Steuergeräte gestartet werden und es können aktuelle Systemzustandsdaten aus dem Kraftfahrzeug abgerufen und ausgelesen werden. Eine Möglichkeit der technischen Realisierung wurde im Zusammenhang mit Fig. 1 erörtert.
Die Verarbeitung der Systemdaten und der Ablauf des Diagnoseprogramms weichen jedoch bei der Erfindung entscheidend vom vorbekannten Stand der Technik ab. Die wichtigsten Unterschiede sind hierbei der interaktive Ablauf des Diagnoseprogramms und die damit verbundene Möglichkeit gezielte Diagnoseschwerpunkte zu bilden, in dem für die Fehlersuche ein oder mehrere Schwerpunkte, im Folgenden Fokusse genannt, gesetzt werden können, und damit sowohl die Diagnosequalität als auch die Diagnosedauer verbessert werden können. Auf die programmtechnische Realisierung wird im Folgenden näher eingegangen:
Das auf dem Computersystem implementierte Diagnoseprogramm zeichnet sich unter anderem durch einen modularen Aufbau aus. Hierdurch werden unter anderem die Programmierung und die Bedatung des Diagnosesystems strukturiert. Mit einem ersten Programmmodul 210, entsprechend seiner Funktion genannt Regeltabellenauswertung, werden die aus dem Kraftfahrzeug abgerufenen Daten, wie Fehlercodes und Systemstatusdaten zu den einzelnen im Kraftfahrzeug verbauten Komponenten, eingelesen und weiterverarbeitet. Die Weiterverarbeitung beinhaltet ein Überprüfen von in einer Wissensbasis 211 abgespeicherten Regeltabellen. Die Regeltabellen beinhalten das für das zu diagnostizierende, technische System relevante Diagnosewissen. Dieses Wissen ist beispielsweise in komprimierter Form in Datentupeln abgelegt. Die Datentupel bilden hierbei die Zusammenhänge der in ihnen enthaltenen Informationen ab. Pro Diagnoseregel ist ein Datentupel abgelegt. Ein Datentupel besteht jeweils aus einer Komponentenkennung Ki, einem Fehlercode FCi, einem Symptom Sympi als Hinweis für eine betroffene technische Funktion, und einem Systemstatus Stat. Die Regeltabellenauswertung erfolgt dann derart, das in der Gesamtheit aller abgelegten Datentupel nachgesehen wird, welche Datentupel den oder diejenigen eingelesenen Fehlercodes enthalten und welche Komponenten Ki und Funktionen Sympi in den identifizierten Datentupeln genannt sind und damit von dem beobachteten Fehler FCi betroffen sein können. Die derart aufgefundenen Komponentenkennungen, werden festgehalten und zu einer ersten Fehlerkandidatenmenge zusammengefasst und abgespeichert. Diese Komponentenkennungen Ki geben einen Hinweis, welche Komponente oder auch welche Funktion des technischen Systems für den beobachteten Fehlercode oder für das beobachtete Fehlersymptom ursächlich sein kann. Ergebnis dieses ersten Durchforsten der Wissensbasis ist eine erste Menge verdächtiger Komponenten, die aufgrund der Identifikation über die Fehlercodes FCi ermittelt wurden.
In einem weiteren Verarbeitungsschritt bzw. Programmmodul 213 wird der durch die erste Kandidatenmenge gebildete Fehlersuchraum weiter auf gespannt. In einem zweiten Durchlauf durch die Wissensbasis werden nun die möglichen Fehlerquellen durch die relevanten Funktionen, die im Kraftfahrzeug betroffen sein können, erweitert. Hierzu werden die Regeltabellen nochmals durchsucht, diesmal jedoch nicht nach festgestellten Fehlercodes, sondern nach den bereits über die Fehlercodes möglicherweise betroffenen Komponenten Ki. Zu den Komponenten werden die möglicherweise betroffenen Funktionen Sympi bestimmt. Diese beiden Mengen müssen nicht identisch sein. Denn es ist möglich, dass ein Fehlercode auf eine Komponente verweist, die für mehrere Funktionen relevant ist. Ergebnis dieses zweiten Durchlaufs durch die Wissensbasis ist eine ergänzte Kandidatenliste 214, die nun neben den möglicherweise fehlerhaften Komponenten auch die möglicherweise fehlerhaften Funktionen enthält.
An dieser Stelle angekommen, beginnt nun die Interaktionsmöglichkeit in den weiteren Ablauf des Diagnoseprogramms. Zunächst wird auf dem
Bildschirmarbeitsplatz 200 eine Abfrage 215 durchgeführt und angezeigt, ob für die weitere Verarbeitung die bereits ermittelten Fehlercodes oder die ermittelten möglicherweise betroffenen Funktionen angezeigt werden sollen. In beiden Fällen wird in einem weiteren Verfahrensschritt 216 dem Servicetechniker die Möglichkeit geboten, für den weiteren Diagnoseablauf einen Fokus zu setzen. Das Setzen des Fokus erfolgt hierbei je nach ausgewählter Anzeige, indem entweder ein angezeigter Fehlercode oder eine angezeigte, verdächtige Funktion Sympi per graphischer Menüsteuerung ausgewählt wird, und der weiteren Verarbeitung durch das Diagnoseprogramm zugrunde gelegt wird. Ist der Fokus gesetzt, wird die weitere Datenverarbeitung auf diesen Fokus beschränkt. D.h. es werden nicht mehr alle bereits ermittelten Fehlercodes, verdächtige Kandidaten oder verdächtige Funktionen betrachtet, sondern nur noch diejenigen, die unter den gewählten Fokus fallen.
Für die noch innerhalb des Fokus verdächtigen Komponenten Ki werden die einzelnen Fehlerkandidaten in einem weiteren Programmmodul bzw. Verfahrensschritt 217 einer Gewichtung unterzogen .
Für die Gewichtung müssen die Wahrscheinlichkeiten der Fehlercodes FCi, die Wahrscheinlichkeit für das Auftreten von Sympi und ggf. die Wahrscheinlichkeit für das Vorliegen von Fehlerbildern errechnet werden. Dazu müssen Wahrscheinlichkeiten bedatet sein, die angeben, mit welcher Sicherheit eine defekte Komponente bzw. ein Kandidat Ki einen Fehlercode (P(FCiIKj)), eine Fehlfunktion (P (Sympi | Kj )) oder ein Fehlerbild (P(FBiIKj)), verursachen. Außerdem wird die relative Fehlergewichtung g(Kj) einer Komponente selbst benötigt. Diese Informationen werden für die Berechnung der priorisierten, bzw. gewichteten Kandidatenliste benötigt. Die bedingten Wahrscheinlichkeiten lassen sich leicht schätzen. Meist sind sie auf „1" gesetzt. Unsichere Symptome oder Fehlercodes können aber mitunter Werte kleiner 1 annehmen. Die Fehlergewichte g(Kj) können aus Erfahrungswissen z.B. zwischen eins und hundert gewählt werden und stellen eine relative Ausfallkenngröße dar. In einer unten erläuterten vorteilhaften Ausführung kann auch über diese Fehlergewichte g(Kj) das aktuelle Feldgeschehen berücksichtigt werden, indem diese Gewichte über Verrechnung von Fehlerhäufigkeiten adaptiert werden.
Alle Wahrscheinlichkeiten und Fehlergewichte werden bei der Bedatung des Diagnosesystems in einer Datenbank 218 abgelegt. Zweckmäßiger Weise können diese zusammen mit der Komponentenliste, der Funktionen- oder Symptomliste und der Fehlerbildliste abgelegt und bedatet werden. Diese Listen werden bei der Konstruktion eines Kraftfahrzeuges erstellt und brauchen daher nur um das Erfahrungswissen hinsichtlich der bedingten Wahrscheinlichkeiten und der Fehlergewichte ergänzt werden. Zweckmäßigerweise erfolgt die Bedatung baureihenspezifisch. Es können jedoch auch Baureihen übergreifende Datenbanken erstellt und herangezogen werden. Bei Baureihen übergreifenden Datenbanken muss dann jedoch die Möglichkeit einer Baureihen spezifischen Auswahl, z.B. in Form einer vorgeschalteten Mastertabelle vorgehalten werden.
Aus den oben erläuterten Daten berechnen sich die Einzelgrößen wie folgt:
P(FCi) = γjg{Kj) - P(FCi I Kj)IG ; Kj verursacht FCi
P(Sympi) = ∑g(Kj)-P(Sympi/Kj)IG ; Kj verursacht Sympi
J=I
P(FBi) = ∑ g(Ki) - P(FBi I Kj)IG ; Kj verursacht FBi
J=I Die drei errechneten Größen werden zur Erstellung der Kandidatenpriorisierung, weiter unten, benötigt. G ist eine Normierungsgröße und wird in einem Vorbereitungsschritt oder per Bedatung z.B. als Summe aller Gewichte g(Kj) festgelegt.
Nachdem die Wahrscheinlichkeiten der Fehlercodes P(FCi), der Fehlerbilder P(FBi) und der Fehlfunktionen P(Sympi) errechnet wurden und die Fokusmenge der Fehle'rkandidaten feststeht, kann die Berechnung einer priorisierten bzw. gewichteten Kandidatenliste 219 angestoßen werden und schließlich auf dem Display des Bildschirmarbeitsplatzes 200 ausgegeben werden.
Die a posteriori Fehlerwahrscheinlichkeit oder Priorität Prio(Ki) einer Komponente Ki ergibt sich aus dem folgenden Produkt:
Pr io(Ki) = (g(Ki)/ G) - fj P(FQ l Ki) - ]J P(Sympk \ Ki) ■ Y[P(FBl \ Ki)
FCj aufgetreten Sympk aufgetreten FBl aufgetreten
Wobei gilt: P(FCiIK)=P(FCi) falls der Fehlercode FCi von einer Komponente K unabhängig ist und analog dazu P (Sympk I Ki)=P (Sympk) und P (FBl | Ki) =P (FBl) bei Unabhängigkeit von der jeweiligen Komponente.
Diese Priorität ist noch unnormiert und kann alternativ noch normiert werden indem durch die Summe aller Kandidatenprioritäten geteilt wird.
Das oben erläuterte Diagnosesystem, das zum Offenbarungsgehalt der hier beschriebenen Erfindung gehört, liefert eine priorisierte Kandidatenliste , und ist das bevorzugte Diagnosesystem, mit dem die Prüfschrittpriorisierung durchgeführt werden kann. Prinzipiell kann die erfindungsgemäße
Prüfschrittpriorisierung jedoch mit jedem Diagnosesystem, das als Diagnoseergebnis eine Fehlerkandidatenmenge liefert, durchgeführt werden.
Der letzte Schritt in der Werkstattdiagnose sind Komponentenprüfungen oder funktionale Tests, mit dem Ziel der vollständigen Fehlereingrenzung zur schnellstmöglichen Abhilfe. Bis zu diesem Zeitpunkt werden alle verfügbaren Informationen, wie Fahrzeugeigendiagnosen oder die Kundenbeanstandungen weitgehend automatisiert ausgewertet. Der letzte Schritt, das Prüfen am Fahrzeug, ist aber meist kosten- und zeitintensiv. Ziel ist es daher diese Fahrzeugprüfungen kostenoptimal zu gestalten, indem Fahrzeugprüfungen in Form eines optimierten Prüfbaumes bzw. Entscheidungsbaumes dem Servicetechniker von seinem Werkstattdiagnosesystem vorgeschlagen werden. Der Schwerpunkt der hier beschriebenen erfindungsgemäßen Prüfschrittpriorisierung liegt hierbei in der Erstellung einer optimierten Prüfungsreihenfolge. Die Prüfschrittpriorisierung 220, geht dabei von einer Fehlerkandidatenmenge aus, deren Fehlerkandidaten bereits in einer Vorstufe identifiziert und benannt wurden. Diese Situation verdeutlicht das Blockdiagramm der Figur 3. Aus Fehlercodes 310 und identifizierten Fehlfunktionen oder Fehlersymptomen 320 wird von einem Diagnosesystem in einer Basisversion eine nicht priorisierte Fehlerkandidatenmenge 330 ermittelt. In bevorzugten Ausführungsformen wird von einem Diagnosesystem eine gewichtete Kandidatenliste 340 ermittelt. In jedem Fall wird von dem Softwaremodul 350 der Prüfschrittpriorisierung 220 zu den ermittelten Fehlerkandidaten die in einer Wissensbasis oder in einer Datenbank 360 abgelegten, relevanten Prüfungen, zu Überprüfung der einzelnen verdächtigen Kandidaten ermittelt. Stehen alle relevanten Prüfungen fest, werden die Einzelprüfungen von der Prüfschrittpriorisierung hinsichtlich Informationsgehalt und/oder Kosten bewertet, priorisiert und in eine PrüfSchrittreihenfolge gebracht. Die Priorisierung der Prüfschritte kann hierbei rekursiv und dynamisch an den Fortschritt der Diagnosesitzung nachgeführt werden, indem bereits durchgeführte Prüfungen vom Servicetechniker in das System eingegeben werden und die verbrauchten Prüfungen aus der PrüfSchrittreihenfolge gelöscht werden. Der Verbrauch einer vorgeschlagenen Prüfung führt in der Regel zu einer neuen Priorisierung einer gewichteten Prüfschrittliste 370, die jeweils aktuell an den Stand der Diagnosesitzung nachgeführt ist.
Für ein Fahrzeug sind in der Regel viele hundert Prüfungen definiert und z.B. in einer Datenbank hinterlegt. Zum Glück müssen während einer Diagnosesitzung nicht alle Prüfungen bewertet werden, sondern nur die für das aktuelle Problem relevanten. Nach Auswertung aller Fahrzeug- und Kundeninformationen wird von dem Diagnosesystem in einer ersten Stufe eine Liste der verdächtigen Komponenten, die Fehlerkandidatenmenge erstellt. Nun können von dem Diagnoseprogramm diejenigen Prüfungen aus einer Prüfschrittdatenbank ausgewählt werden, die für die Überprüfung der verdächtigen Komponenten relevant sind. D.h. diejenigen Prüfungen, die mindestens einen Verweis auf die verdächtigen Komponenten haben. Die Menge aller in der Datenbank abgespeicherten Prüfungen sei PS. Die relevanten Prüfungen seien ps Element von PS. Die grundsätzliche Leitfrage zur Ermittlung der besten Prüfung zum aktuellen Zeitpunkt ist erfindungsgemäß: Wie gut hilft die Prüfung ps im aktuellen Diagnoseproblem, das aus einer Fehlerkandidatenmenge besteht, weiter? Erfindungsgemäß wird hierzu eine von einem Diagnoseprogramm verarbeitbare Entscheidungsfunktion vorgeschlagen, die die relevanten Prüfungen hinsichtlich ihres jeweiligen Informationsgehalt für das jeweilige Diagnoseproblem bewertet, oder die die relevanten Prüfungen für das jeweilige Diagnoseproblem hinsichtlich der jeweiligen Kosten für das Durchführen der Prüfung bewertet, oder die die für das jeweilige Diagnoseproblem relevanten Prüfungen hinsichtlich Effizienz bewertet, wobei die Effizienz durch den Quotienten aus Informationsgehalt und Kosten gebildet wird.
Der Informationsgehalt eines PrüfSchrittes lässt sich z.B. aus seiner Entropie Ent ermitteln. Die Effizienz Eff ist dann das Verhältnis des Informationsgehaltes eines PrüfSchrittes ps zu seinen Kosten:
Eff(ps):= Ent (ps) /costs (ps)
Dabei wird unter der Entropie eines PrüfSchrittes folgende Wahrscheinlichkeitssumme verstanden :
Figure imgf000023_0001
wobei
Zi die möglichen Prüfungsausgänge des Prüfungsschrittes ps, z.B. in Ordnung oder nicht in Ordnung; und p(ps=zi) die Wahrscheinlichkeit für das Prüfungsergebnis zi sind.
Damit wird der Informationsgehalt eines PrüfSchrittes dann am größten, wenn seine Entropie am größten wird. Die Entropie wird am größten, wenn ein Prüfschritt viele Ausgänge, d.h. viele mögliche Prüfergebnisse, hat und wenn die einzelnen Prüfergebnisse einen möglichst Ungewissen Ausgang haben. Dies entspricht der Tatsache, dass ich mit derjenigen Prüfung am meisten Informationen gewinne, die gleichzeitig möglichst viele Fehlerkandidaten abprüft und von der ich am wenigsten weiß, wie die Prüfung ausgeht. Umgekehrt hat diejenige Prüfung den geringsten Informationsgehalt, die nur wenige Ausgänge hat und von der ich das Ergebnis mit großer Sicherheit schon weiß.
In einem bevorzugten Ausführungsbeispiel der Prüfschrittpriorisierung wird die Entscheidungsfunktion zur PrüfSchrittauswahl durch die zu erwartenden Kosten der nach dem ausgewählten Prüfschritt jeweils verbleibenden Prüfschritte für den jeweiligen Rest der voraussichtlichen Diagnosesitzung gebildet. Dadurch werden die Entscheidungsfunktionen der beiden bereits besprochenen Entscheidungsfunktionen hinsichtlich Entropie und Effizienz durch eine verfeinerte und erweiterte Entscheidungsfunktion ersetzt, die hier als Expected Costs of Diagnosis (ECD) bezeichnet wird. Diese Entscheidungsfunktion enthält ebenfalls das Entropie Kriterium, das jedoch durch eine verfeinerte und erweiterte Kostenbetrachtung und Kostenschätzung ergänzt wird. Die verfeinerte und erweiterte Kostenschätzung berechnet bei jedem aktuellen Prüfschritt die voraussichtlichen Kosten für die noch verbleibende Prüfung, d.h. welche Kosten noch zu erwarten sind, nach dem eine vorhergehende Prüfung bereits durchgeführt wurde. Die Bezeichnung der Entscheidungsfunktion als ECD ( Extended Cost of Diagnosis) ist an die Bezeichnung ECR, den Extended Cost of Repair angelehnt, die in der wissenschaftlichen Literatur gelegentlich benutzt wird.
Die bevorzugte Entscheidungsfunktion wird gebildet: ECD(ps) =
Figure imgf000025_0001
p(ps = exitj)
Figure imgf000025_0002
+ EstCosts(ps = exitj) ]
wobei j ein Laufindex und n die Anzahl der nach dem aktuellen Prüfschritt ps noch verbleibenden Prüfungen ist.
Für jede relevante Prüfung ps wird über deren mögliche Prüfungsausgänge (=exits) summiert . Der Summand besteht aus einer Kostenschätzung in den eckigen Klammern EstCosts, die mit der Eintrittswahrscheinlichkeit des betreffenden Prüfungsausgangs P(PS=exit j) multipliziert wird. In der Kostenschätzung werden zum Kostenwert der aktuellen Prüfung ps noch die geschätzten weiteren Kosten addiert. Diese Kosten werden wie folgt geschätzt:
EstCosts(ps = exitj) = (- og p°) • AvCosts(PS)
Figure imgf000025_0003
mit p°= p (Diag=Ki/ps=exit j)
Damit bestehen die geschätzten Kosten EstCosts aus der Entropie des verbleibenden Diagnoseproblems, multipliziert mit den durchschnittlichen Prüfkosten AvCosts. Die letzteren sind das arithmetische Mittel der Kosten aller verbleibenden Prüfungen .
Der jeweils anstehende, auszuwählende Prüfschritt wird dann aus den möglichen Prüfschritten ausgewählt, indem jeweils derjenige Prüfschritt ausgewählt wird, der die Expected Costs of Diagnosis der jeweils verbleibenden Diagnosesitzung minimiert .
Die in den Entscheidungsfunktionen benötigten
Wahrscheinlichkeiten p(ps) und die daraus abgeleiteten Größen der jeweils relevanten Prüfschritte ps werden aus der Priorisierung der Fehlerkandidatenliste berechnet. Zu den ermittelten Fehlerkandidaten Ki werden die relevanten Prüfschritte ermittelt.
Der Prüfschritt ps prüfe gleichzeitig zwei Kandidaten Kl und K2 , wobei der Prüfschritt das Ergebnis „nicht in Ordnung" (niO) hat, wenn einer der beiden Kandidaten sich als fehlerhaft erweist, und das Ergebnis „in Ordnung hat" (iθ) , wenn beide Kandidaten das Prüfergebnis fehlerfrei liefern. Der wahrscheinliche Prüfungsausgang der relevanten Prüfschritte ergibt sich dann aus den Fehlerkandidatenwahrscheinlichkeiten wie folgt:
p(ps=niθ) = (p(Kl=iO) + p (K2=niO) ) /Normierung p(ps=iθ) = (p(Kl=iO) + p (K2=iO) ) /Normierung = 1 - p(ps=niθ)
wobei die Fehlerwahrscheinlichkeiten p (Ki) für die Kandidaten Ki aus der gewichteten Fehlerkandidatenliste genommen werden.
Ein weiteres Kriterium für eine Prüfschrittpriorisierung sind die Kosten für einen durchzuführenden Prüfschritt. Diese Kosten sind als Erfahrungswerte z.B. als so genannte Arbeitswerte bekannt, und werden bei der Erstellung der PrüfSchrittdatenbank mit bedatet und den einzelnen Prüfschritten zugeordnet. Dadurch kann die Entscheidungsfunktion für die Prüfschrittpriorisierung gegebenenfalls von einer Entropie hin zu einer Effizienzauswahl oder einer Kostenschätzung entsprechend der Expected Costs of Diagnosis verfeinert werden.
Die Entscheidungsfunktion für die Prüfschrittpriorisierung des Diagnosesystems ist dann entweder eine
Prüfschrittpriorisierung anhand des Informationsgehaltes des einzelnen relevanten PrüfSchrittes, wobei der Prüfschritt mit dem größten Informationsgehalt die höchste Priorität erhält, oder es wird mit der Entscheidungsfunktion eine Priorisierung der einzelnen Prüfschritte anhand der oben definierten Effizienz durchgeführt, wobei derjenige Prüfschritt die höchste Priorität erhält, der die höchste Effizienz hat, oder es wird eine Kostenschätzung entsprechend der Expected Costs of Diagnosis herangezogen.
Mit jeder der vorgenannten Prüfschrittpriorisierungen lässt sich eine per Computerberechnungen und Computerauswahl automatisiert durchgeführte PrüfSchrittreihenfolge aufstellen. Dem Servicetechniker kann eine PrüfSchrittreihenfolge vorgeschlagen und auf einem Display eines Diagnosesystems zur Anzeige gebracht werden, die mit dem höchst priorisierten Prüfschritt beginnt und die weiteren Prüfschritte mit jeweils abnehmender Priorisierung anschließt .
Damit lässt sich ein Computer gestütztes Diagnosesystem einrichten, dessen Diagnoseprogramm um das Modul einer Prüfschrittpriorisierung erweitert ist. Der Verfahrensablauf für ein Basissystem mit Prüfschrittpriorisierung ist in dem Blockdiagramm der Fig. 4 dargestellt. Startend mit der von dem Diagnosesystem bereitgestellten gewichteten Fehlerkandidatenliste 410 werden von dem erfindungsgemäß ergänztem Diagnoseprogramm in einem anschließenden Verfahrensschritt 420 die relevanten Prüfschritte ermittelt und z.B. mit dem vorgenannten Bewertungsschema hinsichtlich Effizienz, Informationsgehalt oder Kostenschätzung bewertet und priorisiert. In einem folgenden Verfahrensschritt 430 kann der Servicetechniker oder der Monteur aus den angezeigten Prüfschritten einen Prüfschritt z.B. per Menüsteuerung auswählen und am Kraftfahrzeug durchführen. Im folgenden Verfahrensschritt 440 wird das Ergebnis des durchgeführten Prüfschritts in das Diagnosesystem eingegeben und mit der neu gewonnen Erkenntnis eine Neuberechnung der Gewichte der fehlerverdächtigen Kandidaten durchgeführt. Die Neuberechnung führt insbesondere zu einer Streichung aller bereits getesteten und für in Ordnung befundenen Fehlerkandidaten aus der Fehlerkandidatenliste. Die frei werdenden Gewichte wachsen hierbei den noch nicht getesteten Fehlerkandidaten zu. Mit der neu berechneten Fehlerkandidatenliste wird die Prüfschrittpriorisierung ebenfalls neu berechnet und durchgeführt, so dass der Verfahrensablauf für die Prüfschrittpriorisierung rekursiv ist, mit dem Ziel möglichst schnell einen Fehlerkandidaten mit einer Fehlerwahrscheinlichkeit nahe 100% zu erhalten. Verdeutlicht in dem Verfahrensschritt 450 des Blockdiagramms.
Ein Problem bei der Prüfschrittpriorisierung kann die genauere Bestimmung des Informationsgehaltes eines PrüfSchrittes sein, wenn man diesen Informationsgehalt auf die aktuell vorliegende Diagnosesitzung anwenden will. Die vorbeschriebene Gleichverteilung der Prüfungsausgänge ist hier nur eine erste Näherung, die jedoch bei näherem Hinsehen mit dem aktuellen Diagnoseproblem variieren kann. Insbesondere können bereits durchgeführte Prüfungen und die daraus gewonnene Erkenntnis den Informationsgehalt und den Wert noch nicht durchgeführter Prüfungen erhöhen oder vermindern. Will man den Informationsgehalt eines PrüfSchrittes an den Fortgang der Diagnosesitzung anpassen braucht man hierzu ein flexibles Berechnungstool, das in der Lage ist mit Wahrscheinlichkeiten umzugehen. Hier bieten sich Wahrscheinlichkeitsnetze und insbesondere so genannte Bayes Netze an. Bayesnetze werden seit den 80-iger Jahren erfolgreich in den Themenfeldern Fehlerdiagnose, Entscheidungshilfen, Verlässlichkeitsanalysen, Risikobewertung usw. eingesetzt. Die Bayesnetze dienen hierbei der Repräsentation von Zusammenhängen und Größen, die Unsicherheiten unterworfen sein können oder nur der Wahrscheinlichkeit nach bekannt sind. Darüber hinaus bieten die sogenannten Propagierungsverfahren die Möglichkeit neue Informationen, wie z.B. Prüfungsergebnisse, konsistent zu verarbeiten und dadurch den Einfluss auf andere Größen zu berechnen. Das Bayesnetz dient nun dazu die Relationen zwischen Prüfung und geprüfte Komponenten darzustellen und die für die Prüfschrittpriorisierungen benötigten Wahrscheinlichkeiten genauer zu berechnen und an den Fortgang der Diagnosesitzung anzupassen.
Damit lässt sich ein Verfahren zur Prüfbaumerzeugung einrichten. Startend mit einer gewichteten
Fehlerkandidatenliste wird ein Diagnoseknoten eingerichtet, der für jede verdächtige Komponente einen Zustand mit einer Wahrscheinlichkeit, die der Gewichtung der Fehlerkandidaten entspricht, enthält. Nun können diejenigen Prüfungen aus der PrüfSchrittdatenbank ausgewählt werden, die relevant sind, d.h. die die verdächtigen Komponenten prüfen. Die ausgewählten Prüfschritte werden mit einer der Entscheidungsfunktionen priorisiert und ausgewählt. Ein Prüfschritt ist noch verfügbar, wenn er nicht schon einmal durchgeführt wurde, bzw. der Prüfungsausgang nicht schon sicher ist. Für die Prüfbaumkonstruktion müssen dann beide Ausgangsmöglichkeiten der Prüfung, Komponente in Ordnung oder Komponente nicht in Ordnung, vorhanden sein. Dann wird für alle relevanten noch nicht verbrauchten Prüfungen rekursiv fort gefahren. Ein solches Verfahren wird als myoptisch oder kurzsichtig bezeichnet, da immer nur der nächste Schritt optimiert wird. Ist der Prüfbaum aufgespannt können die Ergebnisse der durchgeführten Prüfschritte als Evidenz also als gesichertes Wissen in das Bayesnetz eingegeben werden die Auswirkung auf die verbleibenden Komponenten berechnet werden und zu den übrig gebliebenen Komponenten wieder ein Prüfbaum aufgespannt werden, der mit dem vor beschriebenen myoptischen Verfahren jeweils die höchst priorisierten Prüfschritte auswählt .
Ergebnis ist schließlich ein Prüfschrittbaum, der dem Servicetechniker graphisch zur Anzeige gebracht wird. Eine graphische Repräsentation eines derartigen Prüfschrittbaumes ist in Figur 5 dargestellt. In dem Diagnoseknoten liegen die Zustände der ermittelten Fehlerkandidaten in Form von Gewichten vor. Es seien dies die Kandidaten Kl, K2, K3, K4 , K5. Mit der Entscheidungsfunktion wird für das vorliegende Diagnoseproblem der beste Prüfschritt PSl gewählt. Je nach Ausgang der Prüfung, wird das Prüfungsergebnis zurückgespiegelt. Das Prüfungsergebnis PSl=NOK (Prüfungsergebnis Nicht OK) identifiziert den Fehlerkandidaten Kl. Bei dem Prüfungsergebnis PSl=OK (Kandidat Kl ist in Ordnung) wird mit der
Entscheidungsfunktion die nächst beste Prüfung ausgewählt. Dies sei der Prüfschritt PS4 zur Überprüfung der Komponente K4. Bei dem Ergebnis PS4=N0K ist Komponente K4 als fehlerhaft identifiziert. Ergibt die Überprüfung mit Prüfschritt PS4, dass die Komponente K4 in Ordnung ist, wird mit dem nächst besten Prüfschritt PS2 fortgesetzt, der die Komponente K2 überprüft und bei Prüfausgang Nicht OK K2 identifiziert. Ist das Prüfergebnis OK wird wiederum mit dem besten verbleibenden Prüfschritt fortgesetzt. Bei dem gewählten Beispiel sei dies der Prüfschritt PS3 zur Überprüfung der Komponente K3. Hier ist das Prüfungsergebnis nicht mehr so wichtig, da auf alle Fälle noch die letzte verbliebene, verdächtige Komponente K5 untersucht werden muss. Für diese letzte Überprüfung wird in der Regel noch eine Prüfung fällig, die aber in Figur 5 nicht mehr dargestellt ist. Es kann auch sein, dass ein Restart des Diagnosesystems nach den durchgeführten Reparaturen der Komponenten Kl und K4 ergibt, dass damit auch die Fehlerkandidaten K2,K3,K5 nicht mehr verdächtigt werden.
Realistische Prϋfprobleme können rund 50 verdächtige Komponenten umfassen. Für jede Komponente liegt mindestens eine Einzelprüfung vor. Darüber hinaus gibt es noch funktionale Prüfungen, die mehr als eine Komponente abdecken. Damit liegt die Anzahl der Prüfungen im Allgemeinen über der Komponentenzahl. Durch die Bewertung über die Effizienz werden die Äste eines Prüfschrittbaumes nach ihrer Entropie und nach den Kosten ausbalanciert. Während einer Diagnosesitzung wächst die Fehlerwahrscheinlichkeit und damit die Gewichtung in der Fehlerkandidatenmenge auf wenigen meist einer Komponente an. Die Fehlerwahrscheinlichkeiten aller bereits in Ordnung getesteter Komponenten wird nämlich zu Null und fließt als Prüfergebnis in das Diagnoseprogramm ein, so dass mit fortschreitender Diagnosesitzung und laufender Aktualisierung der gewichteten Fehlerkandidatenmenge durch rekursive Neuberechnung durch das Diagnoseprogramm der Diagnosefokus immer schärfer wird.
Funktionale Prüfungen prüfen in der Regel viele Kandidaten ab, die zum Teil auch außerhalb der Fehlerkandidatenmenge liegen. Diese mitgeprüften externen Kandidaten müssen bei der Berechnung des Informationsgehaltes eines PrüfSchrittes gesondert behandelt werden und dem Servicetechniker ein entsprechender Hinweis gegeben werden. Werden durch das Durchführen der Prüfung die externen Kandidaten als fehlerhaft getestet, kann es zu Widersprüchen mit der Fehlerkandidatenmenge kommen. Ein Update des Prüfschrittbaumes oder der Fehlerkandidatenmenge nach einer positiven Prüfung mit externen Kandidaten darf daher nicht zur vollständigen Entlastung der Kandidaten in der Fehlerkandidatenmenge führen. Dies kann z.B dadurch verhindert werden, dass bei der Fehlerwahrscheinlichkeit zwischen externem pextern und internem Anteil pintem unterschieden wird, und bei der Rückspiegelung des Prüfergebnisses in das Diagnosesystem nur derjenige Anteil zu Null wird, der auch getestet wurde. Der nicht getestete Anteil bleibt dann sowohl in der Fehlerkandidatenmenge als auch in der Prüfschrittpriorisierung. Für funktionale Prüfungen, die auch externe Kandidaten prüfen setzt sich daher die Wahrscheinlichkeit als Summe von externer und interner Wahrscheinlichkeit zusammen.
P = Pextern + Pintern
Der Informationsgehalt oder die Effizienz dieser Verbundprüfungen ist in der Regel sehr hoch, da sie mehrere Komponenten prüfen und daher einen großen Informationsgewinn liefern. Die Verbundprüfungen gehören daher zu den hochpriorisierten Prüfschritten für eine Fehlerkandidatenmenge .
Der Vollständigkeit halber sei noch auf die Möglichkeit von abhängigen Prüfschritten hingewiesen. Manche Prüfschritte bauen aufeinander auf und müssen in einer bestimmten Reihenfolge durchgeführt werden. Diese abhängigen Prüfungen müssen natürlich auch als solche in der PrüfSchrittdatenbank strukturiert sein.
Auch wenn mit dem erfindungsgemäßen Diagnosesystem hauptsächlich sowohl die Fehlerkandidatenmenge als auch die Prüfschrittpriorisierung dynamisch an den Fortschritt der Diagnosesitzung nachgeführt werden und sich sowohl die Fehlerkandidatenmenge als auch die PrüfSchrittauswahl ändern, so kann trotzdem zu jedem Zeitpunkt der Diagnosesitzung , insbesondere beim Kundengespräch in der Fahrzeugannahme, eine aktuelle Kostenabschätzung für die jeweils verbleibende Diagnosesitzung ermittelt werden. Hierzu wird zur Fehlerkandidatenmenge jeweils der komplette Prüfschrittbaum ermittelt und die Kosten der ermittelten Prüfschritte aufsummiert. Diese Kostensumme gibt dann eine Obergrenze für die Kosten an, mit denen beim vorliegenden Diagnoseproblem möglicherweise höchstens zu rechnen sein wird.
Dem Servicetechniker wird ein kompletter Prüfschrittbaum von dem Diagnosesystem vorgeschlagen, bei dem die einzelnen Prüfschritte hinsichtlich Effizienz, Informationsgehalt oder Expected Costs of Diagnosis priorisiert sind. Es bleibt letztlich dem Servicetechniker überlassen, in welcher Reihenfolge er welchen Prüfschritt durchführt. Der Servicetechniker muss nicht mit der höchst priorisierten Prüfung des Prüfschrittbaumes beginnen.
Mit einer optionalen Protokollfunktion können mit dem Diagnosesystem die durchgeführten Reparaturen mitprotokolliert werden. Über dieses Protokoll können dann Prüfungen oder Prüfschritte vorgeschlagen werden, die sicherstellen, dass die eingebauten Komponenten oder die Reparatur nochmals überprüft werden, um sicher zu stellen, dass die Reparatur erfolgreich war und keine neuen Fehler eingebaut wurden. Außerdem kann mit der Protokollfunktion laufend der aktuelle Verbauzustand des Fahrzeugs in der Reparaturwerkstatt mitprotokolliert werden. Damit kann laufend festgestellt werden, welche Komponenten des Kraftfahrzeugs gerade ausgebaut sind. Die dynamischen Kosten der Diagnosesitzung hängen hierbei auch vom aktuellen Verbauzustand des Fahrzeugs ab, so dass die Protokollfunktion auch für die Kostenschätzung mit herangezogen werden kann. Das Tracking des Verbauzustandes des Fahrzeuges in der Reparatur gelingt hierbei über das Mitprotokollieren welche Prüfschritte mit welchem Prüfungsausgang bereits durchgeführt wurden.

Claims

Patentansprüche
1. Rechnergestütztes Diagnosesystem, insbesondere für ein Kraftfahrzeug, das mit einem Diagnoseprogramm durch Systemabfragen und durch Verarbeitung der abgefragten Systemmeldungen oder Systemzuständen eine Fehlerkandidatenmenge erzeugt, dadurch gekennzeichnet, dass die zu den Fehlerkandidaten zugehörige Prüfdomäne aus relevanten Prüfschritten aus einer PrüfSchrittdatenbank ermittelt wird und mit einer Entscheidungsfunktion die relevanten Prüfschritte bewertet werden und eine
Prüfschrittpriorisierung durchgeführt wird.
2. Rechnergestütztes Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass die Entscheidungsfunktion die relevanten Prüfschritte hinsichtlich ihres Informationsgehaltes bewertet.
3. Rechnergestütztes Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass die Entscheidungsfunktion die jeweils auszuwählenden Prüfschritte jeweils nach den nach der Auswahl des aktuellen PrüfSchrittes noch verbleibenden zu erwartenden Kosten der noch verbleibenden Prüfschritte bewertet.
4. Rechnergestütztes Diagnosesystem nach Anspruch 1, dadurch gekennzeichnet, dass die Entscheidungsfunktion die relevanten Prüfschritte hinsichtlich Effizienz bewertet.
5. Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Prüfdomäne durch ein Bayes Netz modelliert wird.
6. Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Prüfdomäne mit einer regelbasierten Wissensbasis modelliert wird.
7. Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Prüfdomäne mit einem mathematisch-physikalischen
Modell modelliert wird.
8. Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass mit der Prüfschrittpriorisierung ein Prüfschrittbaum automatisch und dynamisch aufgespannt und angezeigt wird.
9. Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Fehlerkandidatenmenge eine Menge mit gewichteten
Fehlerkandidaten ist.
10. Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Fehlerkandidatenmenge eine Menge mit ungewichteten
Fehlerkandidaten ist.
11. Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass mit einer Protokollfunktion die durchgeführten Reparaturmaßnahmen mitprotokolliert werden und über dieses Protokoll Prüfungen für die durchgeführten Reparaturmaßnahmen vorgeschlagen werden.
12. Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass der Prüfschrittbaum an den Fortgang der Diagnosesitzung dynamisch angeglichen werden kann.
13. Rechnergestütztes Diagnosesystem nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass
Verbundprüfungen, die mit einer Prüfung mehrer potentielle Fehlerkandidaten testen, möglich sind.
14. Rechnergestütztes Diagnosesystem nach Anspruch 11, dadurch gekennzeichnet, dass ein Tracking durchgeführt wird, mit dem der aktuelle Verbauzustand des Fahrzeugs in der Reparatur erfasst wird.
PCT/EP2006/005572 2005-06-14 2006-06-09 Dynamische priorisierung von prüfschritten in der werkstattdiagnose WO2006133865A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200510027378 DE102005027378B3 (de) 2005-06-14 2005-06-14 Dynamische Priorisierung von Prüfschritten in der Werkstattdiagnose
DE102005027378.5 2005-06-14

Publications (1)

Publication Number Publication Date
WO2006133865A1 true WO2006133865A1 (de) 2006-12-21

Family

ID=36699183

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/005572 WO2006133865A1 (de) 2005-06-14 2006-06-09 Dynamische priorisierung von prüfschritten in der werkstattdiagnose

Country Status (2)

Country Link
DE (1) DE102005027378B3 (de)
WO (1) WO2006133865A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013202064A1 (de) * 2013-02-08 2014-08-14 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zum Verbinden eines Diagnosegeräts mit einem Steuergerät in einem Kraftfahrzeug
CN110689147A (zh) * 2019-09-28 2020-01-14 东方航空技术有限公司 一种飞机故障快速诊断***及方法
CN111465543A (zh) * 2017-12-19 2020-07-28 大众汽车有限公司 用于在自动驾驶车辆的情形中执行自诊断的方法
CN113762907A (zh) * 2020-10-13 2021-12-07 北京沃东天骏信息技术有限公司 一种审核对象的方法和装置

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8213321B2 (en) 2007-02-01 2012-07-03 Deere & Company Controller area network condition monitoring and bus health on in-vehicle communications networks
DE102007034151A1 (de) 2007-07-21 2009-01-22 Daimler Ag Funktionsorientierte Fehlerdiagnose von Kraftfahrzeugen
EP2284631A1 (de) * 2009-07-17 2011-02-16 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Fahrzeugdiagnosesystems, Steuerungsprogramm und Fahrzeugdiagnosesystem
US8509985B2 (en) 2011-05-25 2013-08-13 GM Global Technology Operations LLC Detecting anomalies in fault code settings and enhancing service documents using analytical symptoms
DE102011086352A1 (de) 2011-05-31 2012-12-06 Robert Bosch Gmbh Verfahren und Diagnosesystem zur Unterstützung der geführten Fehlersuche in technischen Systemen
US8863499B2 (en) * 2012-05-10 2014-10-21 GM Global Technology Operations LLC System for indicating quality of a diesel exhaust fluid (“DEF”)
DE102015219981A1 (de) * 2015-10-14 2017-04-20 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Überprüfen eines in einem Kraftfahrzeug mit einem Verbrennungsmotor vorgesehenen SCR-Systems
JP7276701B2 (ja) * 2018-12-20 2023-05-18 ダイハツ工業株式会社 故障診断システム
US11514731B2 (en) * 2019-08-29 2022-11-29 Launch Tech Co., Ltd. Method and system for remote vehicle diagnostics
DE102022211838A1 (de) 2022-11-09 2024-05-16 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zur Diagnose von beim Betrieb eines Fahrzeugs auftretenden Fehlern und Mittel zu dessen Implementierung

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030167111A1 (en) * 2001-02-05 2003-09-04 The Boeing Company Diagnostic system and method
WO2004074955A1 (de) * 2003-02-21 2004-09-02 Audi Ag Vorrichtung und verfahren zur modellbasierten on-board-diagnose
DE10315344A1 (de) * 2003-04-03 2004-12-30 Audi Ag Verfahren und Vorrichtung zur Erkennung fehlerhafter Komponenten in Fahrzeugen

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5107497A (en) * 1989-07-28 1992-04-21 At&T Bell Laboratories Technique for producing an expert system for system fault diagnosis
EP0443212B1 (de) * 1990-02-22 1997-06-11 Koninklijke Philips Electronics N.V. Verfahren zur Durchführung einer rechnergestützten Diagnose von physikalischen Fehlern mittels eines Expertsystems
JP2985505B2 (ja) * 1991-07-08 1999-12-06 株式会社日立製作所 品質情報収集診断システム及びその方法
CA2188023A1 (en) * 1994-04-26 1995-11-02 Robert T. Clark Machine failure isolation using qualitative physics
DE19523483C2 (de) * 1995-06-28 1998-10-22 Daimler Benz Ag Rechnergestützte Fehlerdiagnoseeinrichtung für ein komplexes technisches System
US6535865B1 (en) * 1999-07-14 2003-03-18 Hewlett Packard Company Automated diagnosis of printer systems using Bayesian networks
GB0127553D0 (en) * 2001-11-16 2002-01-09 Abb Ab Provision of data for analysis
DE102004024262A1 (de) * 2004-05-15 2005-12-01 Daimlerchrysler Ag Wissensbasiertes Diagnosesystem für ein komplexes technisches System mit zwei getrennten Wissensbasen zur Verarbeitung technischer Systemdaten und zur Verarbeitung von Kundenbeanstandungen

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030167111A1 (en) * 2001-02-05 2003-09-04 The Boeing Company Diagnostic system and method
WO2004074955A1 (de) * 2003-02-21 2004-09-02 Audi Ag Vorrichtung und verfahren zur modellbasierten on-board-diagnose
DE10315344A1 (de) * 2003-04-03 2004-12-30 Audi Ag Verfahren und Vorrichtung zur Erkennung fehlerhafter Komponenten in Fahrzeugen

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013202064A1 (de) * 2013-02-08 2014-08-14 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zum Verbinden eines Diagnosegeräts mit einem Steuergerät in einem Kraftfahrzeug
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
CN111465543A (zh) * 2017-12-19 2020-07-28 大众汽车有限公司 用于在自动驾驶车辆的情形中执行自诊断的方法
US11787423B2 (en) 2017-12-19 2023-10-17 Volkswagen Aktiengesellschaft Method for carrying out a self-diagnosis in an automated vehicle
CN110689147A (zh) * 2019-09-28 2020-01-14 东方航空技术有限公司 一种飞机故障快速诊断***及方法
CN113762907A (zh) * 2020-10-13 2021-12-07 北京沃东天骏信息技术有限公司 一种审核对象的方法和装置

Also Published As

Publication number Publication date
DE102005027378B3 (de) 2006-11-16

Similar Documents

Publication Publication Date Title
DE102005027378B3 (de) Dynamische Priorisierung von Prüfschritten in der Werkstattdiagnose
WO2006105930A1 (de) Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben
DE10244131B4 (de) Verfahren zur Unterstützung einer Identifizierung einer defekten Funktionseinheit in einer technischen Anlage
DE602004009683T2 (de) Fahrzeug-diagnoseverfahren, fahrzeug-diagnosesystem, fahrzeug und zentrale
DE10307342B4 (de) Vorrichtung und Verfahren zur modellbasierten On-Board-Diagnose
DE102004024262A1 (de) Wissensbasiertes Diagnosesystem für ein komplexes technisches System mit zwei getrennten Wissensbasen zur Verarbeitung technischer Systemdaten und zur Verarbeitung von Kundenbeanstandungen
DE102011117803A1 (de) Verfahren für die Wartungsdiagnose- und Wartungsprozedurverbesserung
DE102005046388A1 (de) Modellgestützte Diagnose und Reparatur mittels Ereignisprotokollierung
DE102012100390A1 (de) Entwickeln eines Fehlermodells aus Servicebeschreibungen
DE102007010978A1 (de) Verfahren und Vorrichtung zur Unterstützung einer Diagnose eines elektrischen Systems mittels wahrscheinlichkeitsbasierter Fehlerkandidatenermittlung
EP1307816A1 (de) System zur ermittlung von fehlerursachen
DE102010052998A1 (de) Software-zentrierte Methodik für die Überprüfung und Bestätigung von Fehlermodellen
EP2866111B1 (de) Testen eines Steuergerätes mittels einer Testumgebung
DE102011086352A1 (de) Verfahren und Diagnosesystem zur Unterstützung der geführten Fehlersuche in technischen Systemen
DE102009027267A1 (de) Verfahren und Vorrichtung zur vereinfachten Fehlerverarbeitung an einer Werkzeugmaschine
DE10146901A1 (de) Verfahren und System zur Bearbeitung von Fehlerhypothesen
DE102008004219A1 (de) Verfahren zum Behandeln mindestens eines Fehlers innerhalb eines Systems
DE102021114087A1 (de) Selektive Meldesysteme für Funktionszustandsinformationen, die integrierte Diagnosemodelle enthalten, die Informationen über die geringst- und höchstmögliche Ursache bereitstellen
DE10315344B4 (de) Verfahren und Vorrichtung zur Erkennung fehlerhafter Komponenten in Fahrzeugen
DE102012007321A1 (de) Verfahren zum Betreiben eines Diagnosesystems und Diagnosesystem
EP2284631A1 (de) Verfahren zum Betrieb eines Fahrzeugdiagnosesystems, Steuerungsprogramm und Fahrzeugdiagnosesystem
DE102012211787A1 (de) Fahrzeugdiagnosevorrichtung zum Ermitteln eines Bedarfs für eine Überprüfung von mindestens einer Komponente eines Kraftfahrzeuges und Fahrzeugdiagnoseverfahren zum Ermitteln eines Bedarfs für eine Überprüfung von mindestens einer Komponente eines Kraftfahrzeuges
DE102018212801A1 (de) Diagnose komplexer Systeme
DE102013004949B4 (de) Fehlersuchgerät zur Fehlersuche bei der elektronischen Inbetriebnahme und/oder Prüfung von hergestellten Kraftfahrzeugen
DE102022105249A1 (de) Verfahren zum prüfen von obd-relevanz eines eingangssignals

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06754273

Country of ref document: EP

Kind code of ref document: A1