DE102022210276A1 - Method for detecting defects in a system - Google Patents

Abstract

The invention relates to a method for detecting defects in a system (100), comprising detecting (200, 210, 220) parameter values for a plurality of status indicators of the system, the status indicators being measured parameters (200) of the system and/or measured parameters include calculated or modeled parameters (220) for the system; determining, for each of the condition indicators, a current evaluation indicator for a defect based on a comparison of the recorded parameter values for the condition indicator with predetermined reference values; determining a defect probability for at least one component of the system (100) based on a combination of the evaluation indicators for a predetermined group of condition indicators, each of which is assigned to the at least one component.

Description

The present invention relates to a method for detecting defects in a system as well as a computing unit and a computer program for carrying it out.

Background of the invention

Various options are used to monitor functionality and detect errors in vehicles. This includes, among other things, onboard diagnostics in the control unit for various functions, which continuously monitors and models certain parameters and measured values and checks the results for compliance with specified limit values. If errors or unexpected results are detected, signals (e.g. warning lamp lighting up, information displayed on a display) can be issued to a user or read by a workshop.

The aim of such diagnostics is always to isolate a source of error as precisely as possible (pin pointing). If the defective unit cannot be identified, components must be replaced on suspicion, which is time-consuming and costly. For example, a diagnostic element could indicate an increase in a certain emission value without it being clear which component is causing this undesirable increase. It is also possible that there is no isolated error and therefore no error entry for an individual component in the control unit, but rather an interaction of several components causing a deviation.

Disclosure of the invention

According to the invention, a method for detecting defects in a system as well as a computing unit and a computer program for carrying it out are proposed with the features of the independent patent claims. Advantageous refinements are the subject of the subclaims and the following description.

The invention presents an improved diagnostic option for detecting and isolating errors in a system such as a vehicle. In particular, a method is proposed in which parameter values for a large number of status indicators of a system are first recorded, the status indicators comprising measured parameters of the system and/or parameters for the system calculated or modeled from measured parameters. A current evaluation indicator for a defect is then determined for each of the condition indicators, the evaluation indicator being determined on the basis of a comparison of the recorded parameter values for the condition indicator with predetermined reference values. Based on a combination of the evaluation indicators determined in this way for a predetermined group of condition indicators, a defect probability for at least one component of the system is then determined, the group of condition indicators being assigned to the at least one component. Through the combined evaluation of several status indicators on a probability basis, errors or changes can also be detected that are not yet reflected in individual threshold value violations or error displays. The evaluation indicator can initially represent a key figure specific to a status indicator, whereby the evaluation indicators do not have to be comparable to one another. An evaluation indicator can, for example, indicate a probability value for an error condition or defect condition, but also a distance of the parameter values from a limit, a distance of a distribution of parameter values from typical values or similar key figures. For example, a deviation of 3 sigma from the fleet mean value or a percentile value (e.g. 97th percentile) for a specific parameter can be determined as the distance.

Furthermore, a diagnostic probability can be determined in the method, which indicates a probability for possible diagnostic steps for further testing and/or isolating an error or a defect in a component, which indicates which of the possible diagnostic steps is most relevant for testing or isolating the error . The diagnostic steps can, for example, be a leak test of the air system or the coolant system or a test of the turbocharger boost pressure build-up, depending on an underlying system error or higher-level defect. The determination of the diagnosis probability is based on a combination of the evaluation indicators for a predetermined group of status indicators, each of which is assigned to at least one diagnostic step. Furthermore, the diagnostic effort of the possible diagnostic steps as well as the determined probability of defects can also be included in the determination. By determining the probability of diagnosis, it is possible to specifically name the necessary diagnostic steps for fault isolation in a workshop and to display the diagnostic steps in an efficient sequence with regard to the probability of the defect and the diagnostic effort, whereby the fault diagnosis and thus the repair of the system can be carried out efficiently.

In addition, the method can also be used to determine a cause probability of a defect-error possibility, which indicates a probability for various defect-error possibilities as to which error exists that triggers the underlying system error or the higher-level defect. The possible defects include, for example, insufficient cooling capacity or an internal leakage of the cooling water. As was already the case for the defect and diagnosis probability, the determination of the cause probability can be based on a combination of the evaluation indicators for a predetermined group of condition indicators that are assigned to a defect error possibility. This means that during repairs in the workshop it can be shown what caused the system error or the higher-level defect, thus further narrowing down the troubleshooting. This can make repairing the system easier. The processes described below for determining the probability of defects and/or probability of diagnosis can be applied in the same way to determining the probability of cause.

Determining a current evaluation indicator for a status indicator can, for example, include at least one of the following: comparing the parameter values with one or more threshold values specified as a reference value; Comparing the parameter values with reference values that were determined for the status indicator in one or more other systems; Comparing the parameter values with reference values that were recorded from statistical characteristics of a plurality of parameter values for the condition indicator in a plurality of other systems; Comparing the parameter values with parameter values of the system specified as a reference value that were recorded at one or more previous times.

Determining a current evaluation indicator for each of the condition indicators may include, among other things, determining a difference between the parameter value and the reference value, and setting the evaluation indicator depending on the determined difference. By determining the difference, a measure of how far the measured parameter value is from a specified defect threshold or how far the parameter value is from a value expected to be normal is recorded, and this measure can then be used in determining the evaluation indicator for a defect. A parameter that is close to a defect threshold is more likely to indicate a current or impending defect.

Optionally, the status indicators can be classified into relevance groups. The relevance groups can depend on the underlying system error or higher-level defect for which the procedure is carried out. For example, the underlying system error can be an increase in NOx emissions measured by a NOx tailpipe sensor, although other emissions (NH3, CO, HC, ...) are also conceivable. Furthermore, the underlying system error or the higher-level defect can also be an increase in the consumption of resources or energy, increased noise emissions, increased vibration of the product or, in general, any change in the product. In the aforementioned example, the relevance groups are emission relevance groups for NOx emissions, with each status indicator being divided into a relevance group based on its relevance for the NOx emissions. For example, three relevance groups (high, medium, low) can be formed to which the status indicators are assigned. However, it is also possible that only two or more than three relevance groups are formed. Each relevance group is also assigned a relevance factor. When divided into three relevance groups, the relevance factors can, for example, have the value 1 (high), 2/3 (medium) and 1/3 (low). However, it is also possible that the relevance factors have uneven distances, for example 0.95 (high), 0.50 (medium) and 0.25 (low). Furthermore, relevance factors with values greater than 1 are also conceivable. The evaluation indicators are then obtained by multiplying the established evaluation indicator by the relevance factor depending on the relevance group of the condition indicator. By dividing into relevance groups based on the underlying system error, the accuracy of determining the defect probability for a component and/or the diagnosis probability for a diagnostic step can be increased.

Determining the defect probability for at least one component of the system and/or the diagnosis probability for at least one diagnostic step can include determining a combination of evaluation indicators based on existing combinations. The existing combinations can, for example, be stored on an external server or cloud storage and come from series data from a fleet of similar or identical systems. For example, it can be concluded from the series data that some combinations occur very rarely or never in reality, while other combinations may occur frequently. The probability of failure for at least one component of the system and/or the diagnostic probability for at least one diagnostic step can then be carried out based on the specific combination of the evaluation indicators. By using series data to determine the combination, the combinations of evaluation indicators can be limited to the frequently occurring combinations and thus the computing power for determining the defect probability for at least one component of the system and/or the diagnosis probability for at least one diagnostic step can be reduced and their determination accuracy increase. Furthermore, it can also be checked whether a specific combination of evaluation indicators and the resulting defect and/or diagnosis probability match the defective component or whether the correct diagnostic step has been determined, whereby the existing combinations can be further adapted and thus the determination of the defect. and/or diagnosis probability can be further specified.

Determining a defect probability for at least one component of the system and/or the diagnosis probability for at least one diagnostic step can include weighting each evaluation indicator with a weighting factor. The weighting factor can be, for example, a probability that results from information from a diagnostic possibility analysis (DMA) or guided troubleshooting (GFS) in a workshop. This information is already available before the start of production of the system and results from engineering and empirical knowledge that may come from older systems and/or was previously determined in a validation fleet. The probability of defects for at least one component of the system and/or the probability of diagnosis for at least one diagnostic step are then determined based on the values of the weighted evaluation indicators. For example, the probability of defects or the probability of diagnosis can be set to the highest value among the values of the evaluation indicators. Alternatively, it is also possible for all evaluation indicators relevant for a component to be included proportionately in the defect probability or diagnosis probability. By weighting the evaluation indicators with empirical values available before the start of production of the system, which are incorporated into the process, the detection of an error or defect can be improved.

Acquiring parameter values can include, among other things, obtaining parameter values as output signals from a sensor; and/or receiving parameter values as an output value of a calculation module that is set up to calculate a parameter value from input values, and/or receiving parameter values via a communication connection. In particular, the parameter values can be recorded in the system (for example in a control unit of a vehicle) in which the defect is to be recognized, while the steps described above for evaluating the parameter values and determining a defect probability are carried out in another device (for example on a workshop computer , a server or computing network) and are recorded for this purpose via a communication connection. Stored data (e.g. data from other vehicles, or other data from the production of the components, status of the control unit in the vehicle) from a remote or cloud storage option or from a remote server can also be received and processed.

Optionally, it can be checked for at least one status indicator whether a predetermined condition was fulfilled during the acquisition of the parameter value, and if this was not fulfilled, the associated parameter value can be discarded. Alternatively, the condition can be checked during a measurement or calculation of a parameter value, and if the condition is not met, the measurement is rejected or the calculation is not carried out. For example, the existence of a suitable meaningful operating range can be specified as a condition, e.g. the existence of a stationary or quasi-stationary operating point or a defined operating range with certain limits.

The status indicators can in particular include parameters that describe a measured deviation from a predetermined normal state and/or include parameters that describe a measure of the health status of at least one component of the system.

It is also possible for a message to be issued to a user if the probability of defects for a component exceeds a predetermined threshold value. The threshold can be the same or different for each component and can also be adjusted if necessary. This can be used to indicate to a user, for example, that it makes sense to check a specific subsystem in order to detect safety-critical errors in a timely manner.

Optionally, it is also possible to provide information about an actual defect and/or replacement of a component of the system and/or diagnostic steps carried out. Such information can be obtained, for example, through user input or through automatic recognition of a replaced component. This information can then be compared with a determined defect probability for the component, ie it can be checked, for example, whether a high determined defect probability correlated with an actual defect or whether there was a misjudgment. The information can also be compared with a determined diagnostic probability for the diagnostic steps, ie it can be compared which diagnostic steps were carried out and whether a high diagnostic probability was determined for them, i.e. whether they were able to help isolate the error. On the basis of this comparison, the determination of the evaluation indicators and/or the determination of the defect probability or the diagnosis probability can then be adjusted, for example by changing the assignment of the predetermined group for at least one condition indicator; Changing a calculation specification to determine the evaluation indicator; Changing a calculation specification to determine the probability of defects and/or the probability of diagnosis; or changing a weighting of a condition indicator for determining the probability of defect and/or the probability of diagnosis. This means that the evaluation system, which continuously records the probability of defects from parameter values, can be continuously improved and adjusted so that more precise diagnoses are possible.

Parameter values for one or more condition indicators can be recorded in particular over time, so that the course can also be taken into account to determine the evaluation indicator for defects, for example sudden changes versus slow changes over a long period of time. It is also possible for parameter values that were recorded over time to be used, for example, to form average values, which can then be used to form the evaluation indicators.

The method steps described are particularly suitable, for example, for monitoring and diagnostics in a vehicle. In a vehicle, a large number of parameter values are usually already recorded, modeled and processed by a control unit or another unit, so that at least some of these values can be used as status indicators for the steps mentioned above. Such methods can also be used in other systems in which certain parameter values can be checked continuously or at certain intervals, e.g. in stationary or mobile fuel cells, electric drives or other forms of drive. In principle, it can be used in all systems in which defects can occur and information can be recorded, and therefore in most technical systems and production systems.

Overall, with the variants described, it is possible to identify defective or aged components in a system, to carry out targeted repairs, but also to estimate for future periods which components could fail, and thus enable spare parts planning, for example at the manufacturer. Even without detected defects, such methods can be used to develop measures for potential problem areas at an early stage, e.g. by adapting software modules in the control system, or by replacing components with parts with improved properties, before an error occurs.

A computing unit according to the invention, for example a control unit of a motor vehicle, is set up, in particular in terms of programming, to carry out a method according to the invention.

The implementation of a method according to the invention in the form of a computer program or computer program product with program code for carrying out all method steps is also advantageous, since this causes particularly low unit costs, especially if an executing control device is used for additional tasks and is therefore available anyway. Finally, a machine-readable storage medium is provided with a computer program stored thereon as described above. Suitable storage media or data carriers for providing the computer program are, in particular, magnetic, optical and electrical memories, such as hard drives, flash memories, EEPROMs, DVDs, etc. It is also possible to download a program via computer networks (Internet, intranet, etc.). Such a download can be wired or wired or wireless (e.g. via a WLAN network, a 3G, 4G, 5G or 6G connection, etc.).

Further advantages and refinements of the invention result from the description and the accompanying drawing.

The invention is shown schematically in the drawing using exemplary embodiments and is described below with reference to the drawing.

Brief description of the drawings

• 1 shows an exemplary system with a vehicle and a processing unit for executing method steps; and
• 2 shows exemplary process steps in a flowchart.

Embodiments of the invention

The following examples refer to vehicles as a system in which various data is recorded, evaluated and/or forwarded. 1 shows an example of a vehicle 100 as a system for which data is to be evaluated based on probability in a processing unit 130. For this purpose, one or more control devices 110 are often present in the vehicle 100, which control data acquisition centrally or specifically for a specific function (eg measurement at fixed intervals). Likewise, the data recorded in such control devices can also be at least partially evaluated, used for calculations and modeling and used for controls and regulations in the vehicle. However, the methods described can generally be transferred to any system in which a status diagnosis is of interest and various data is recorded, such as construction machines, automatic production machines, fuel cells, feed drives, turbines or others. Also in such systems there is usually a corresponding control unit 110 such as a control device, a microcontroller or a similar element that is able to at least control the acquisition of various data. The measurement data itself can be recorded by any sensors and measuring devices 120, 122, 124, such as temperature sensors, pressure sensors, mass flow sensors, tachometers, vibration or sound sensors, accelerometers and others. The sensors 120, 122, 124 are shown here only schematically as an example; It goes without saying that a large number of different sensors are usually used in different subsystems in a vehicle or other system. Such measured values can be used directly or included in modeling and calculations from which various parameters are obtained.

The methods described here can be used to evaluate large amounts of data in order to enable a system to be diagnosed, even in difficult cases. The data can be collected, processed and aggregated in a suitable manner and, for example, transferred to a remote server 130 or another suitable computing unit. There this data can be used to carry out a probability-based diagnosis. Based on this diagnosis, decisions regarding on-site diagnosis, replacement of components or other further steps can then be carried out.

A diagnostic result can also be obtained or improved by including collected data from other vehicles 140 in the evaluation. These can be stored, for example, in a remote server or cloud storage so that an evaluating unit 130 can access them. These may also be collected and aggregated in similar or different ways. The comparison with fleet data 140 can also be combined with an evaluation for the individual vehicle. In particular, the diagnosis can be influenced by a suitable selection of the monitored features, their aggregation and the combined evaluation. The evaluation can be designed in such a way that older data from an individual vehicle or other vehicles can be included in the evaluation, thus creating a learning diagnostic system whose results are continually improved over time.

The data used for evaluation are generally referred to below as condition indicators. Many different values, calculation parameters and modeling parameters can be considered as status indicators. In particular, a large number of parameters can also be evaluated that are already recorded to implement other functions or are available on a control device. This generally means that no additional parameters need to be recorded or determined as status indicators. However, it is also possible that certain parameters, calculations or evaluations are only used as a status indicator and are therefore provided specifically for this purpose.

2 shows exemplary process steps, which are described in more detail below. Steps 200 to 240 can be done, for example, in the control unit 110 1 expire. In step 200, parameter values can first be measured, for example obtained from sensors. In step 210, additional parameter values may also be formed from measured parameter values and other input values through calculations, modeling, and similar processes. In step 220, parameter values obtained in this way can be further aggregated in order to reduce the amount of data required for evaluating the status indicators. For example, average values of parameters can be formed over a specific time window, individual discrete measured values at specified times or a predetermined number of measured values, for example the last measured value, the last ten measured values or any other number of measured values, are selected, or only values are taken into account that meet certain boundary conditions or for whose measurement such boundary conditions were met. The final parameter values obtained in this way for various status indicators can then be saved at least temporarily in step 230. These steps of recording, aggregating and storing can of course be repeated as often as desired; Typically, the parameter values are recorded and processed continuously or at predetermined intervals as long as the system is in operation. In step 240, the parameter values for the status indicators stored in this way can optionally be transmitted to a suitable evaluation unit 130, which can be, for example, a remote server or a workshop computer. Finally, in step 250, the collected status indicators can be evaluated.

• Parameter mit einem kontinuierlichen oder kleinschrittigen diskreten Format (z.B. ein Prozentwert);
• Parameter, die nur wenige Messgrößen und/oder wenige Daten zur Übertragung erforderlich machen (z.B. Parameter, die nur einmal pro Fahrzyklus oder einmal nach einer vorgegebenen Fahrtstrecke erfasst werden);
• Parameter, die möglichst unabhängig von Betriebspunkten, Fahrsituationen und Umgebungsbedingungen sind; und
• Parameter, die mit anderen Zustandsindikatoren vergleichbar sind, optional auch mit Zustandsindikatoren anderer Komponenten.

Parameters with the following properties are particularly, but not exclusively, suitable as status indicators:

• Parameters with a continuous or small-step discrete format (e.g. a percentage value);
• Parameters that require only a few measured variables and/or a small amount of data to be transmitted (e.g. parameters that are only recorded once per driving cycle or once after a specified driving distance);
• Parameters that are as independent as possible of operating points, driving situations and environmental conditions; and
• Parameters that are comparable to other health indicators, optionally also to health indicators of other components.

Although these properties bring various advantages for evaluation, they should not be viewed as absolutely necessary; It is also possible to at least partially consider parameters as status indicators that do not meet all of these properties, e.g. binary ratings or parameters that are recorded very frequently. For example, a parameter can also be recorded at very short intervals, e.g. for a control, but only a selected part of the recorded parameter values can then be evaluated as a status indicator. Likewise, a single value for a status indicator can be formed from several values for a parameter by averaging or other statistical operations, e.g. by a moving average over specified time windows. The load counters described below as status indicators do not have to be independent of operating points and driving situations, for example. Furthermore, data that cannot be recorded or measured directly in the vehicle can also be included. These can, for example, be contributed by the workshop staff via an input mask on a workshop computer. Examples of such data are delays in starting the engine: engine does not start at all, engine starts with a strong delay (after more than 5 s), engine starts with a delay, engine starts with jerks, engine only starts sometimes or engine only starts when the engine is cold.

For clarity, possible health indicators can be divided into two groups. On the one hand, parameters that describe a deviation of a component or a measured value measured in the vehicle from a normal state or limit value are suitable as status indicators. These condition indicators are referred to below as diagnostic features. On the other hand, parameters are suitable as indicators that record the load on components, such as counting load changes on a component. These status indicators are referred to below as load counters. However, it is understood that status indicators that cannot be classified into these two groups can also be included in an evaluation.

A large number of parameters that are usually available in control devices anyway can be used as status indicators from the class of diagnostic features.

Possible diagnostic features as status indicators can be, for example, physical states of components. This includes directly measured physical values, such as values for pressure, temperature, mass flow or any other values recorded by suitable sensors. Likewise, parameters from measured values can also be determined as physical states using a physical model.

As an example, a radiator ventilation level can be determined from the measured values of temperature, pressure and mass flow sensors as well as the vehicle speed using a physical model and used as a status indicator. This value is suitable as a status indicator for any cooling device, such as an intercooler, engine cooler, exhaust gas recirculation cooler, a cooler for battery cooling, a cooler for fuel cell cooling, or others. The determination of suitable sizes as condition indicators for various coolers continues described in more detail below in connection with an exemplary embodiment for a diesel engine air system.

Another physical quantity that can serve as a status indicator is, for example, a conversion efficiency of a catalytic converter determined from sensor measurements and models, or the storage capacity of a substrate determined from sensors and models (e.g. NH3 storage capacity of an SCR catalytic converter). A further example is a flow resistance parameter calculated from a differential pressure sensor, as can be determined, for example, over a particle filter, a catalytic converter, an exhaust gas recirculation line, a fuel cell stack or at other suitable points in a system.

Another group of status indicators that can be counted among the diagnostic features are learning values from sensors and actuators, which are usually taught in and used in the control unit to correct values, so that these values are often already present. In particular, these can be learning values that, for example, describe the drift behavior of sensors or actuators, e.g. the drift of an air mass sensor, or the learned deviation of a pressure sensor when it is compared with the ambient pressure in a suitable operating state.

Learning values relating to the injection behavior of injectors, e.g. for an injector quantity adjustment, or learning values of the “open” and “closed” stops of flaps or valves can also be used, which can indicate mechanical defects or contamination, for example

Counters of various functions can also serve as diagnostic features and thus as status indicators. This is especially true for counters that describe how often a regeneration function has been activated for a component. The underlying systems often change as a result of such regeneration processes, so that the regeneration becomes less effective as the number of processes increases. In a similar way, counting regeneration processes and similar processes can serve as a counter for specific stress conditions and thus aging of the component. For example, a counter for the number of particle filter regenerations can be used as a status indicator. During a particle filter regeneration, the temperature is temporarily increased significantly in order to burn off particle deposits. Such a counter can, for example, indirectly indicate the increasing ashing of the filter. In addition, an accumulation of necessary regeneration processes can indicate other underlying defects, such as increased soot formation from engine combustion in a diesel engine. The distinction as to whether it is a matter of ashing in the filter or another defect that leads to increased soot formation can be determined, for example, using other diagnostic variables or load counters (e.g. the total mileage in km since the current filter element was used). As a further example, a counter can be used as a status indicator that counts the number of tear-away functions for flaps. Such functions use short actuator pulses, for example to release iced-up flaps.

Debounce times of functions can also be used as a status indicator or can be used to derive status indicators from them. Debounce times are defined as time limit values so that when there are changes in the state of a signal input, for example, the change is only registered when a certain period of time has passed or when the state has occurred over a certain period of time. For this purpose, a counter or timer can be started as soon as a certain signal, a certain state or a certain value occurs for the first time. After the specified debounce time has been reached, the signal can be further processed as such. Debounce times can generally be set for signal changes or state changes at a signal input as well as for changes in relation to certain limit values (e.g. an upper threshold). This means that debounce times can also be set for defect detection; An error is therefore only recognized, saved or displayed as such after the associated debounce time has expired. For example, when controlling the air mass in the engine, short-term deviations are normal and cannot be avoided, especially in transient driving situations; On the other hand, longer lasting deviations indicate an error. Accordingly, a debounce time can be set for the deviation signal. Debounce times can be found in many common diagnostic functions in control devices and can therefore be used as a status indicator for evaluation in a simple manner and without additional effort.

For example, if the maximum debounce time in a driving cycle or within a specified driving distance (e.g. per 100 km route) is recorded for a diagnostic function, this value can be used in conjunction with the threshold value set for a defect to determine how far the Components were away from the defect detection threshold.

The so-called error ratio or an error quotient can be used as a further value for a status indicator. The error ratio can be the time in which a defect in a component is suspected (e.g. based on a threshold value being exceeded) in relation to the time in which the component is considered to be error-free. The error ratio, alone or in conjunction with the error condition used, can provide a measure of how far the component is from the defect detection threshold.

Control parameters from a control system can also be used as status indicators. For example, closed-loop control parameters can be recorded and evaluated, in particular the integrator portion (I portion) of a closed-loop control. In a controller, the I component primarily ensures the steady correction of an error. In many functions, the I component in stationary states is therefore close to zero for a defect-free case, so that conversely a deviation indicates a possible drift or a defect in connection with the variable to be controlled. Since such control parameters can be highly dependent on the operating point, they can also be recorded and evaluated as a histogram or frequency distribution depending on certain operating parameters, i.e. recorded separately for different operating ranges, for example.

As an example, various possible status indicators from the area of diagnostic features are suggested below, which can be used to monitor the status of an air system of a diesel engine.

As physical states of components, for example, pressure, temperature and mass flow in various areas of the air system can be used as status indicators or to form status indicators. For example, the efficiencies of various coolers in the air system can be used as status indicators.

The efficiency of a high-pressure exhaust gas recirculation cooler can be determined, for example, from the following measured values: a temperature downstream of the high-pressure exhaust gas recirculation cooler; a modeled exhaust gas temperature before exhaust gas recirculation cooling; a modeled pressure before exhaust gas recirculation cooling; a measured intake manifold pressure; a calculated mass flow through the high-pressure exhaust gas recirculation, which can be determined, for example, from the measured values of an air mass sensor, the intake manifold pressure, the intake manifold temperature and the engine speed; and a coolant temperature of the high-pressure exhaust gas recirculation cooler.

Common physical models can be used for the modeled values, which are used, for example, to regulate the air system or to monitor certain values in the exhaust gas.

As another example, the cooling efficiency of a low-pressure exhaust gas recirculation cooler can be determined from the following measurements: the temperature downstream of the low-pressure exhaust gas recirculation cooler; a modeled exhaust gas temperature before the low-pressure exhaust gas recirculation cooling; a modeled exhaust gas pressure before exhaust gas recirculation cooling; a measured or modeled pressure in front of the turbocharger, or a pressure at the air mass sensor or an ambient pressure; a calculated mass flow through the low-pressure exhaust gas recirculation, which can be determined, for example, from the measured values of an air mass sensor, the intake manifold pressure, the intake manifold temperature and the engine speed or alternatively from the differential pressure across the low-pressure exhaust gas recirculation route and temperatures and pressure in the low-pressure exhaust gas recirculation route; and a coolant temperature of the low pressure exhaust gas recirculation cooler.

Finally, the cooler efficiency of an intercooler can also be determined from measured values, namely, for example, by the following variables: a measured temperature downstream of the intercooler; a modeled temperature before the intercooler, e.g. the temperature after the turbocharger compressor, which is calculated from a compressor model; the pressure in the intercooler, e.g. the boost pressure before or after the intercooler; the mass flow through the low-pressure exhaust gas recirculation section, which, for example, consists of the measured values of an air mass sensor, the intake manifold pressure, the intake manifold temperature and the engine speed and, if necessary. when using low-pressure exhaust gas recirculation, the differential pressure across the low-pressure exhaust gas recirculation section and temperatures and pressure in the low-pressure exhaust gas recirculation section can be determined; and a coolant temperature of the low-pressure exhaust gas recirculation cooler (for liquid-cooled intercoolers) or the vehicle speed or a control of an intercooler fan (for air-cooled intercoolers).

For an air system, all three efficiencies or even just one or two of these efficiencies can be selected as status indicators.

The determination of an efficiency as a status indicator from these measured values can be done, for example, by forming an average of parameter values (measured, calculated or modeled values) take place over a specified period of time. It can also be specified that only values that were recorded in predetermined operating ranges are used for evaluation as a status indicator. For example, it could be specified that only values in steady state, stationary or quasi-stationary operation are used as status indicators in the evaluation. Alternatively or additionally, valid operating ranges for the evaluation could be defined as status indicators based on threshold values, so that in the above examples only values of operating points could be taken into account at which the mass flow or the coolant temperature is in a certain value range or above a certain threshold value. Additionally or alternatively, it can be checked whether there is a sufficiently large temperature difference between the coolant temperature and the exhaust gas temperature at the cooler inlet, and optionally also, for example, by setting a time period as a threshold value, whether such a condition has already existed for a certain time. If such a parameter is already used for a diagnostic function and a valid operating range is specified for it, the same validity parameter can also be used as a status indicator. Alternatively, a different validity condition can be selected for use as a status indicator than for a diagnostic function.

For example, in a controller intended to control the air system, a cooler efficiency may be provided as a parameter, and another quantity may indicate as "true" or "false" whether the associated values were recorded in an appropriate operating range. This variable for evaluating the valid operating range can therefore be used as a trigger condition for the validity of the cooler efficiency as a status indicator, so that all determined values for the cooler efficiency that were recorded in a valid operating range are saved as a status indicator and / or transmitted to an evaluating unit can.

In the air system, for example, the deviation from an air mass sensor value compared to a modeled mass flow through the engine with the exhaust gas recirculation valves closed can be considered as a status indicator from the area of the learning values of sensors and actuators. The modeled mass flow through the engine with the exhaust gas recirculation valves closed results from the intake manifold pressure, the intake manifold temperature and the engine speed. This modeled value can then be compared again with measured values that were recorded under specified valid operating conditions (e.g. closed exhaust gas recirculation valves, stationary operation, air mass flow within specified limits) and optionally averaged. The determined deviation between the modeled and the measured air mass value can then be saved, transmitted and evaluated as a status indicator. In addition, the currently measured air mass value can also be used as a separate status indicator. The course of the deviation factor over the air mass can be evaluated if several adjustments are carried out with different air masses. A linear deviation, i.e. constant factors over the air mass range, then suggests a fault in the air mass sensor, while deviations with increasing factors over an air mass range tend to indicate sooting of the intake manifold, e.g. due to deposits from the exhaust gas recirculation system or the crankcase ventilation. If unexpectedly falling deviation factors occur, an error due to defective, heavily dirty or incorrectly cleaned air filters can be suspected, for example.

Debounce times can be used in the air system, for example to control the air mass, and can be evaluated as described above. Likewise, debounce times and corresponding timers or debounce counters can be used in boost pressure control and used as status indicators. Other areas in which debounce times are used and a corresponding counter can be available are flow monitoring of the exhaust gas recirculation, which checks whether too much or too little exhaust gas is passed through the recirculation and thus enables conclusions to be drawn about a dirty line or malfunctioning of the valves. In turn, diagnoses can be carried out separately for different operating areas, and the associated values can also be evaluated separately as status indicators.

Error ratios as described above can be taken, for example, from a sooting detection of a high-pressure exhaust gas recirculation system, which can optionally also be provided with validity conditions for the operating range. Monitoring the speed of the exhaust gas recirculation system can also work with error ratios, whereby, for example, positive and negative deviations in the error ratios can be used separately as indicators.

Finally, as closed-loop control parameters in the air system, parameters of the boost pressure control, the air mass control, the exhaust gas recirculation control or the position control of the various actuators (e.g. the valves, throttle valve, exhaust gas flap, the turbocharger actuator or the swirl flaps) can be evaluated as status indicators.

All of the above-mentioned condition indicators for the air system can be evaluated individually and/or together in order to be able to isolate the respective defective component from an error in the air system.

It is understood that both the groups and subdivisions mentioned for the status indicators and the specifically listed parameters are only mentioned as examples and that, in principle, any value or parameter in a system can be used as a status indicator, which is at least partially influenced by a specific system status could and thus conversely can also be evaluated for condition assessment.

As already described, values can also be used as status indicators that are assigned to the class of load meters.

For example, to record the mechanical load on a component, the number of vibration cycles for different amplitudes can be recorded and compared with predetermined values for component design. Such load values can be represented, among other things, using so-called rainflow diagrams or Wöhler curves, which are known in the art. The comparison with the component design could be used as a status indicator, as could the vibration counter itself. The recording of minimum and/or maximum forces acting on a component or of the forces acting per defined driving cycle can also be used as a status indicator.

To record thermal loads, for example, a temperature distribution at durability-relevant points of a component can be recorded or modeled, so that it is recorded in which temperature ranges the components were operated over which time periods. Likewise, minimum and/or maximum values of the temperatures during a driving cycle could also be evaluated here. Analogous to the mechanical oscillations in the previous example, temperature oscillation cycles, i.e. cycles of heating and cooling over certain temperature ranges, can also be recorded. Since component loads occur during such temperature fluctuations, these parameters can also be evaluated as condition indicators for analyzing durability.

In addition, variables are suitable as condition indicators that describe the maintenance status of a vehicle, e.g. the recording of certain service procedures, oil change intervals, or the replacement of a (partial) component.

For example, to monitor a turbocharger, the following load counter status indicators can be used as a basis: an operating time in a specified temperature range, e.g. how long the turbocharger was operated at a temperature above a predetermined (high) threshold; analogously, an operating time in a defined speed range, e.g. how long the turbocharger was operated above a certain speed threshold; how often strong loads such as high speeds or high temperatures occurred when the turbocharger was cold, i.e. strong load changes occurred; the number of temperature changes above a certain temperature difference threshold; how often an engine was stopped while hot (risk of oil coking in the bearing); the number or intervals of oil changes; the ratio between short-distance trips and long-distance trips for the vehicle.

It goes without saying that the associated threshold values for the operating ranges can initially be chosen arbitrarily and, for example, can be designed in such a way that, in particular, operating ranges that are expected to place a particularly high load on a component are included in the evaluation. However, it is also possible for the load counter values described to be recorded and evaluated for all operating areas, or for a load counter value for selected high-load operating points to be used generally as status indicators in addition to a load counter value for all operating areas. The time periods to which the counters refer can also be chosen appropriately; In particular, load counters can be taken into account over the entire period of use of a component, but depending on the value used, it is also possible to reset a load counter under certain conditions.

The values recorded as status indicators can then first be stored in aggregated form, for example on a memory element of a control device. Data from various networked control devices can also be collected and stored centrally.

The values collected in this way can then be evaluated. For evaluation, it is possible in particular for the recorded values for the status indicators to be transferred to a suitable processing unit that can provide sufficient computing power for the necessary evaluations for a large number of parameters. Such a processing unit can, for example may include a remote server, a workshop PC, a central controller or any other device with, for example, a processor, a microcontroller, suitable volatile and non-volatile memory elements or similar components capable of carrying out the method steps explained. A transmission to a processing unit can take place, for example, via a wireless or wired communication connection, for example via a mobile phone network and a corresponding interface that is available in the vehicle, or via a cable connection in a workshop service. The data can be transmitted collectively, for example at predetermined times, at regular time intervals or upon request, or can also be transmitted after each determination or calculation, for example each time the corresponding diagnostic feature is calculated by the control unit. It is also possible to store the values locally as raw values or in aggregated form, for example as a minimum value, average value and maximum value, and then to transmit these aggregated values, for example, at the end of a driving cycle or after a predetermined driving distance (e.g. every 100km). The values stored in the vehicle can then optionally be deleted or reset after the transfer.

The optimal transmission frequency as well as the number and selection of stored values can also take into account the available storage capacity and the available transmission means, e.g. bandwidth and costs of data transmission. In addition, when determining the storage and transmission conditions, it can also be taken into account how often a specific status indicator is determined or calculated and how high the accuracy or fluctuation of an individual value is. It is possible that status indicators are defined that do not provide an evaluable result in every driving cycle, since certain operating states must be present over a certain period of time in order to provide a valid result. Other status indicators can lead to a large number of recorded values in a short period of time, which can be used for evaluation as individual values or in aggregated form. Different transmission conditions can also be set for different status indicators or different subgroups of status indicators. For example, the load counters can be transmitted in longer periods of time, while the continuously recorded diagnostic features are transmitted more frequently. Additional conditions or triggering conditions may also apply to the transfer; In this way, it can be specified that when an error is detected by a conventional diagnostic function in the control unit, all currently collected values for status indicators or, for example, a certain number of other values that could be related to this error, are immediately transmitted outside the usual transmission cycle.

In the evaluating system, various of the following evaluation steps can then be carried out individually or in combination.

In particular, the status indicators for the diagnostic features can be compared with predetermined threshold values. These can be the same threshold values that are used for a diagnostic function; alternatively, other limit values can be set for the same parameters for the probability-based evaluation. In addition to a simple check as to whether a threshold value is exceeded or fallen below, the distance between the recorded value and the respective threshold value can optionally also be determined and, for example, a weighting or an evaluation indicator for a possible defect can be derived from the distance (or the distance can itself be used as an evaluation indicator). A greater distance from a threshold value for a defect that has not yet been reached indicates a lower probability of a defect, while a smaller deviation from the threshold value can indicate an increased probability of a defect. Through this direct or indirect comparison of the parameter values with predetermined values, evaluation indicators can be obtained for each status indicator based on the current parameter values, which are, for example, probability values, distance values or similar key figures. These current evaluation indicators do not yet have to be comparable with one another, but rather represent key figures in relation to the condition indicator. An evaluation indicator can, for example, indicate a probability value for an error condition or defect condition, but also a distance of the parameter values from a limit, a distance of a distribution of parameter values from typical values or similar key figures. For example, a deviation of 3 sigma compared to the fleet average value for a specific parameter can be determined as the distance. The determination of the evaluation indicator can be specified differently for each condition indicator.

It is also possible to compare the recorded status indicators of an individual system, for example a vehicle, with the values for the same status indicators of other, comparable systems, for example with a vehicle fleet that also provides these values at least in part. It can be assumed that most of the systems have their determined status s indicators are available, have a defect-free condition, so that statistical characteristics of the condition indicators of a large number of other systems (e.g. from averaged values for the respective condition indicator, from a standard deviation, from frequency distributions or other derived values) and a comparison with the condition indicators of the individual system, a conclusion can be made about the functionality or condition of the individual system. For example, if one or more values of an individual system deviate significantly from the average of the same parameter value of many other systems, this may indicate a defect. Alternatively, the individual value can be compared with any other value and only the deviation values determined can be evaluated using statistical methods. Here too, for example, depending on the deviation determined between the individual data and the summarized data from other systems, an evaluation indicator for a defect could be output.

Through a combination of defect threshold values (e.g. from diagnostic functions or specifically for the condition indicators) and comparison with the values of other systems that are considered defect-free on average, improved statements can be made about the recorded values. The two comparisons can be used to set a defect probability between, for example, 0% (value corresponds to the average value of the other systems) and 100% (value exceeds the defect limit of a diagnostic function), so that corresponding probabilities are also specified for all values in between.

The time course of one or more status indicators can also be used for evaluation. If a parameter changes slowly over time and/or distance traveled, this may indicate a slow drift that is likely to continue and can be extrapolated accordingly. This allows the probability of failure to be determined. If, on the other hand, a parameter changes suddenly and remains at the new value, this change can optionally initially be associated with driving conditions that occurred at that time (e.g. increased temperature, longer journey under full load). An unexpected sudden change can otherwise indicate a spontaneous defect in a component, even if the actual defect thresholds for a diagnosis have not yet been reached.

Furthermore, the various status indicators can be divided into relevance groups that depend on the underlying system error. Those status indicators that have a higher relevance to the underlying system error are divided into a different relevance group than status indicators that have a lower relevance to the underlying system error. Each relevance group is further assigned a relevance factor that is greater for the relevance groups with higher relevance than for relevance groups with lower relevance to the underlying system error. The status indicators are then multiplied by the relevance factor assigned to the relevance group.

The condition indicators from the group of load meters can be compared with specified design goals for the design of the components. If the load counters have values near or above the design targets, the probability of a defect may also be increased here compared to lower load counter values.

In particular, a combined evaluation of diagnostic features and load counters for a component or a subsystem allows an improved diagnosis compared to just one of these groups.

The evaluation of the status indicators can specify a single probability or a similar evaluative key figure as an evaluation indicator for each of the recorded values. From a combination of these evaluation indicators, an overall probability of a defect in one or more components or a subsystem made up of several components or the diagnosis probability for a diagnostic step can then be determined. The combination of the evaluation indicators can be determined, for example, from a stock of existing combinations. These existing combinations can be combinations that result from the evaluation of fleet data. In reality, some combinations of evaluation indicators may occur rarely or not at all, while others may occur very frequently. The choice of combination of evaluation indicators can therefore be limited to one of the frequently occurring combinations. The individual evaluation indicators can also be weighted so that certain deviations or errors are weighted higher than others for a specific defect. The weighting factor can result in particular from information from a diagnostic possibility analysis (DMA) or a guided troubleshooting (GFS) in a workshop, which is already available before production of the system starts, since it comes from empirical values or was determined in advance in a validation fleet.

It can also be specified which status indicators are directly or indirectly related or are relevant for a specific component, for example by grouping the status indicators into different groups, by specifying weights or in another way. The selection of these groups can be preset and obtained on the basis of common defect detection. For example, it can be specified which status indicators the failure of an individual catalytic converter will have an impact on, and these status indicators can then be evaluated together to detect defects in the catalytic converter. Each status indicator can be assigned to any number of groups. For example, a change in a specific exhaust gas parameter can occur due to defects or deterioration in several different components, so that the associated condition indicator is grouped for each of these components. Since the groups can still differ in their overall composition, this makes it possible to narrow down the error more precisely. Changes in the parameter values of condition indicators that are not related to the respective component can therefore be ignored.

In principle, the evaluation of the status indicators can also be carried out using machine learning, e.g. using one or more neural networks. For example, the recorded condition indicators themselves and/or the evaluation indicators determined from the threshold value comparisons, comparisons with fleet values and other determinations can serve as input data for a neural network. By recording status indicators for systems over a longer period of time and linking the respective values for the status indicators with error-free times or with effects that actually occurred, labeled training data for supervised machine learning can be created. Additionally or alternatively, unsupervised learning methods can also be chosen in order to recognize structures in the deviations of several status indicators. For example, a defect probability for a specific component can then be output as an output value. Alternatively or additionally, a classification of the current system state into several classes can be carried out as an output value, whereby, for example, an error-free state can form a class as well as any possible defect in a component or an entire system.

The evaluation system can optionally also include further information in order to continuously improve the evaluation.

If, for example, further diagnostic steps, including manual ones, are carried out in a workshop, the results of the diagnostics can be recorded and transmitted back to the evaluation system. This means that the result of the evaluation system can be enriched, confirmed or refuted with additional indicators. The calculations of the defect probabilities or the weightings of the individual condition indicators in the overall assessment can then be adjusted accordingly. Similarly, replaced defective components can optionally be examined and the results, which may include precise details of the defect, reported back to the evaluation system. Together with the measurement data and condition indicators for these components recorded over time, conclusions can then be drawn about the connection between condition indicators and defects.

Values of the condition indicators can also be compared before and after a repair or service process. If the condition indicators have changed, i.e. if an effect of the repair is visible in the condition indicators, the assignment and weighting of the probability evaluation can be confirmed. If, on the other hand, there is no change in the measured values, even though a component has been replaced, for example, it can be checked in more detail whether there is a defect in another component. In addition, in such a case, the assignment of the respective status indicator to a component or a subsystem or the weighting of the status indicator can be checked and changed.

Even if an improvement can be seen after a repair, but overshoots or undershoots or other indications of defects occur again within a shorter specified time, it can be checked in a similar way whether a defect in another component or a multiple error in the interaction of several Components are present.

In principle, it is also possible for the evaluation steps described to be carried out directly in a vehicle or locally on a stationary device that is to be monitored in this way. For example, if there are sufficiently powerful processing units such as a complex control device that can carry out such calculations, a transfer to another processing unit is not absolutely necessary, but can be carried out in addition. If a local evaluation is carried out, the necessary additional values and parameters such as fleet data can be used Reconciliation and updated threshold values are transmitted from a remote server or other device to the local processing unit. For example, an evaluation of collected fleet data could take place in a remote server, from which current threshold values or weights could be derived for an individual evaluation and these derived threshold values or weights could then be sent to the local processing unit, where they can be used for the evaluation.

In particular, the know-how models described above, which are based on the experience of skilled workers in a workshop and data determined in a validation phase, can be converted into fleet data-based models or hybrid models made up of know-how and fleet data. This means that the probability of defects in individual components or diagnostic options can be improved using series data. In addition, it is also possible to take the temporal influence of individual condition indicators into account, so that, for example, defects that only occur after many years of operation or after a certain number of kilometers can be identified in an improved manner.

To do this, the fleet data collected in similar systems and stored on a remote server or cloud storage and the data collected in the system can be used to classify the fleet's systems and the system under investigation into different groups. For example, data on the emission level of various exhaust gas species (NOx, NH3, CO, HC, ...) can be collected and the systems can be assigned, for example, to a group with low emissions and a group with high emissions, in particular separately for each exhaust gas species. If a high emission value then occurs in the system to be examined and it is therefore assigned to the group of systems with high emissions, only those fleet data can be used to determine the probability of defects and/or diagnosis probability, for example when determining the combination of the evaluation indicators systems that are assigned to the same group. In addition, by dividing the system into different groups, it is possible to determine which status indicators or combinations thereof have no influence on an underlying system error or higher-level defect, even in the case of abnormal values. For example, if condition indicators or combinations of various condition indicators show abnormal values for both vehicles in the low emissions group and vehicles in the high emissions group, it is less likely that these condition indicators or combinations of condition indicators will be relevant to determining the underlying system failure or higher-level defect. However, if abnormal values of condition indicators or combinations of various condition indicators only occur in the group of vehicles with high emission values, these are particularly relevant for determining the probability of defects and/or diagnosis. Therefore, by dividing the fleet systems and the system under investigation into different groups, for example based on the emissions level, the weighting of the individual status indicators or the determination of the combinations of assessment indicators to be used can be improved.

Conversely, as soon as there is enough fleet data, a model can be developed that can be used, for example, to model the emissions level, but also any other relevant system error. Such a model can be created using machine learning or other AI applications. From this, for example, it can be determined in advance what influence a changing value of a status indicator could have on the emissions level in the future. This allows the relevant combinations of condition or evaluation indicators with which the defect and/or diagnosis possibility is determined to be determined in an improved manner. A time course of one or more status indicators can also be extrapolated and a future point in time when an emission level will be exceeded or a system error will occur can be determined and a warning message can be displayed to the user of the system at an early stage.

In particular, by including the data on which repairs were carried out, i.e. which components were ultimately replaced, and what influence this repair had on, for example, the emission level or on the individual condition indicators, a model can be developed that can be used to determine what influence the The replacement or repair of one or more components has an impact on the condition indicators. In combination with the previously described model, which determines the emission level based on the condition indicators, it can be determined which component or components should be replaced or repaired, for example in order to move the emission level or another system error back into a permissible range. In particular, for example, the costs of the components and/or their availability or delivery time can be taken into account in order to ensure the most timely and possible delivery to enable cost-effective repair of the system.

Claims (17)

Method for detecting defects in a system (100), comprising: Detecting (200, 210, 220) parameter values for a plurality of status indicators of the system, the status indicators comprising measured parameters (200) of the system and/or parameters (220) for the system calculated or modeled from measured parameters; Determining, for each of the condition indicators, a current evaluation indicator for a defect based on a comparison of the recorded parameter values for the condition indicator with predetermined reference values; Determining a defect probability for at least one component of the system (100) based on a combination of the evaluation indicators for a predetermined group of condition indicators, each of which is assigned to the at least one component. Procedure according to Claim 1 , wherein the method further comprises: determining a diagnosis probability for at least one diagnostic step based on a combination of the evaluation indicators for a predetermined group of status indicators, each of which is assigned to the at least one diagnostic step. Procedure according to Claim 1 or 2 , wherein determining a current evaluation indicator for a condition indicator comprises at least one of the following: comparing the parameter values with one or more threshold values specified as a reference value; Comparing the parameter values with reference values that were determined for the status indicator in one or more other systems; Comparing the parameter values with reference values that were recorded from statistical characteristics of a plurality of parameter values for the condition indicator in a plurality of other systems; Comparing the parameter values with parameter values of the system specified as a reference value that were recorded at one or more previous times. Method according to one of the preceding claims, wherein determining a current evaluation indicator for each of the condition indicators comprises: Determining a difference between the parameter value and the reference value, and Setting the evaluation indicator depending on the difference determined. Procedure according to Claim 4 , wherein determining a current evaluation indicator for each of the condition indicators further comprises: classifying the condition indicators into relevance groups, and determining the evaluation indicator by multiplying the determined evaluation indicator by a relevance factor depending on the relevance group of the condition indicator. Method according to one of the preceding claims, wherein determining the defect probability for at least one component of the system (100) and/or determining the diagnosis probability for at least one diagnostic step comprises: Determining combinations of evaluation indicators based on existing combinations, and Determining the defect probability for at least one component of the system (100) and/or diagnosis probability for at least one diagnostic step based on the specific combination of the evaluation indicators. Method according to one of the preceding claims, wherein determining a defect probability for at least one component of the system (100) and/or determining the diagnosis probability for at least one diagnostic step comprises: Weighting each evaluation indicator with a weighting factor, and Determining the defect probability for at least one component of the system (100) and/or diagnosis probability for at least one diagnostic step based on the weighted evaluation indicators. Method according to one of the preceding claims, wherein the acquisition of parameter values comprises at least one of the following: Obtaining parameter values as output signals of a sensor; obtaining parameter values as an output value of a calculation module configured to calculate a parameter value from input values; Receiving parameter values via a communication link. Method according to one of the preceding claims, wherein for at least one status indicator it is checked whether a predetermined condition was fulfilled during the acquisition of the parameter value, and if this was not fulfilled, the associated parameter value is discarded. Method according to one of the preceding claims, wherein the status indicators include parameters that describe a measured deviation from a predetermined normal state, and/or include parameters that describe a measure of a load on at least one component of the system. Method according to one of the preceding claims, further comprising: Issue a notification to a user if the probability of defect for a component exceeds a predetermined threshold. Method according to one of the preceding claims, further comprising: Obtaining an indication of an actual defect and/or replacement of a component of the system and/or diagnostic steps taken; Comparing the information with a determined defect probability for the component and/or diagnosis probability for the diagnostic steps; and Adjusting the determination of the evaluation indicators and/or adjusting the determination of the defect probability and/or adjusting the determination of the diagnosis probability based on the comparison, the adjustment comprising at least one of the following: Changing the assignment of the predetermined group for at least one status indicator; Changing a calculation specification to determine the evaluation indicator; Changing a calculation specification to determine the probability of defects; Changing a weighting of a condition indicator for determining the probability of defects; Changing a calculation specification to determine the probability of diagnosis; Changing a weighting of a condition indicator for determining the probability of diagnosis. Method according to one of the preceding claims, wherein parameter values for one or more status indicators are recorded in a time and/or distance-based course. Method according to one of the preceding claims, wherein the system is a vehicle (100). Computing unit (110, 130), which is set up to carry out all method steps of a method according to one of the preceding claims. Computer program that causes a computing unit to carry out all process steps of a process according to one of the Claims 1 until 14 to be carried out when it is executed on the computing unit. Machine-readable storage medium with a computer program stored on it Claim 16 .

Images