CA2467230A1 - System and method for processing a new diagnostics case relative to historical case data and determining a ranking for possible repairs - Google Patents
System and method for processing a new diagnostics case relative to historical case data and determining a ranking for possible repairs Download PDFInfo
- Publication number
- CA2467230A1 CA2467230A1 CA002467230A CA2467230A CA2467230A1 CA 2467230 A1 CA2467230 A1 CA 2467230A1 CA 002467230 A CA002467230 A CA 002467230A CA 2467230 A CA2467230 A CA 2467230A CA 2467230 A1 CA2467230 A1 CA 2467230A1
- Authority
- CA
- Canada
- Prior art keywords
- case
- new
- similarity
- ranking
- cases
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2257—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using expert systems
Abstract
Method and system are provided for processing a new diagnostics case relative to historical case data for a machine undergoing diagnostics. The method allows providing a database 12 storing historical case data for the machine undergoing diagnostics. The method further allows calculating a degree of similarity (e.g., 14) between the new case and respective cases stored in the database. A list of neighboring cases is determined relative to the new case based on the calculated degree of similarity between the new case and the respective cases stored in the database. The list of neighboring cases is processed (e.g., 16) to determine a ranking for possible corrective actions for the new case. A corrective action is selected for the new case based on the ranking of the possible corrective actions for the new case.
Description
SYSTEM AND METHOD FOR PROCESSING A NEW DIAGNOSTICS CASE
RELATIVE TO HISTORICAL CASE DATA AND DETERMINING A RANKING
FOR POSSIBLE REPAIRS
BACKGROUND OF THE INVENTION
The present invention relates generally to diagnostics of railroad locomotives and other self powered transportation equipment, and, more specifically, to system and method for processing a new diagnostics case relative to historical case data and determine a ranking for possible repairs. This ranking may be used for condensing knowledge gained from screening cases similar to the new case for the type of machine undergoing diagnostics.
A machine, such as a locomotive or other complex systems used in industrial processes, medical imaging, telecommunications, aerospace applications, power generation, etc., includes elaborate controls and sensors that generate faults when anomalous operating conditions of the machine are encountered. Typically, a field engineer will look at a fault log and determine whether a repair is necessary.
Approaches like neural networks, decision trees, etc., have been employed to learn over input data to provide prediction, classification, and function approximation capabilities in the context of diagnostics. Often, such approaches have required structured and relatively static and complete input data sets for learning, and have produced models that resist real-world interpretation.
Another approach, Case Based Reasoning (CBR), is based on the observation that experiential knowledge (memory of past experiences or cases) is applicable to problem solving as learning rules or behaviors. CBR relies on relatively few pre-processing of raw knowledge, focusing instead on indexing, retrieval, reuse, and archival of cases. In the diagnostic context, a case generally refers to a problem/solution description pair that represents a diagnosis of a problem and an appropriate repair. CBR assumes cases described by a fixed, known number of descriptive attributes. Conventional CBR systems assume a corpus of fully valid or "gold standard" cases that new incoming cases can be matched against.
U.S. Patent No. 5,463,768 discloses an approach that uses error log data and assumes predefined cases with each case associating an input error log to a verified, unique diagnosis of a problem. In particular, a plurality of historical error logs is grouped into case sets of common malfunctions. From the group of case sets, common patterns, i.e., consecutive rows or strings of data, are labeled as a block.
Blocks are used to characterize fault contribution for new error logs that are received in a diagnostic unit. Unfortunately, for a continuous fault code stream where any or all possible fault codes may occur from zero to any finite number of times and where the fault codes may occur in any order, predefining the structure of a case is nearly impossible.
U.S. Patent No. 6,343,236, assigned in common to the same assignee of the present invention, discloses system and method for processing historical repair data and fault log data, which is not restricted to sequential occurrences of fault log entries and which provides weighted repair and distinct fault cluster combinations, to facilitate analysis of new fault log data from a malfunctioning machine. Further, U.S.
Patent No. 6,415,395, also assigned to the same assignee of the present invention, discloses system and method for analyzing new fault log data from a malfunctioning machine in which the system and method are not restricted to sequential occurrences of fault log entries, and wherein the system and method predict one or more repair actions using predetermined weighted repair and distinct fault cluster combinations.
Additionally, U.S. Patent No. 6,336,065, assigned to the: same assignee of the present invention, provides system and method that uses snapshot observations of operational parameters from the machine in combination with the fault log data in order to further enhance the predictive accuracy of the diagnostic algorithms used therein.
That invention further provides noise reduction filters, to substantially eliminate undesirable noise, e.g., unreliable or useless information that may be present in the fault log data andlor the operational parameter data.
RELATIVE TO HISTORICAL CASE DATA AND DETERMINING A RANKING
FOR POSSIBLE REPAIRS
BACKGROUND OF THE INVENTION
The present invention relates generally to diagnostics of railroad locomotives and other self powered transportation equipment, and, more specifically, to system and method for processing a new diagnostics case relative to historical case data and determine a ranking for possible repairs. This ranking may be used for condensing knowledge gained from screening cases similar to the new case for the type of machine undergoing diagnostics.
A machine, such as a locomotive or other complex systems used in industrial processes, medical imaging, telecommunications, aerospace applications, power generation, etc., includes elaborate controls and sensors that generate faults when anomalous operating conditions of the machine are encountered. Typically, a field engineer will look at a fault log and determine whether a repair is necessary.
Approaches like neural networks, decision trees, etc., have been employed to learn over input data to provide prediction, classification, and function approximation capabilities in the context of diagnostics. Often, such approaches have required structured and relatively static and complete input data sets for learning, and have produced models that resist real-world interpretation.
Another approach, Case Based Reasoning (CBR), is based on the observation that experiential knowledge (memory of past experiences or cases) is applicable to problem solving as learning rules or behaviors. CBR relies on relatively few pre-processing of raw knowledge, focusing instead on indexing, retrieval, reuse, and archival of cases. In the diagnostic context, a case generally refers to a problem/solution description pair that represents a diagnosis of a problem and an appropriate repair. CBR assumes cases described by a fixed, known number of descriptive attributes. Conventional CBR systems assume a corpus of fully valid or "gold standard" cases that new incoming cases can be matched against.
U.S. Patent No. 5,463,768 discloses an approach that uses error log data and assumes predefined cases with each case associating an input error log to a verified, unique diagnosis of a problem. In particular, a plurality of historical error logs is grouped into case sets of common malfunctions. From the group of case sets, common patterns, i.e., consecutive rows or strings of data, are labeled as a block.
Blocks are used to characterize fault contribution for new error logs that are received in a diagnostic unit. Unfortunately, for a continuous fault code stream where any or all possible fault codes may occur from zero to any finite number of times and where the fault codes may occur in any order, predefining the structure of a case is nearly impossible.
U.S. Patent No. 6,343,236, assigned in common to the same assignee of the present invention, discloses system and method for processing historical repair data and fault log data, which is not restricted to sequential occurrences of fault log entries and which provides weighted repair and distinct fault cluster combinations, to facilitate analysis of new fault log data from a malfunctioning machine. Further, U.S.
Patent No. 6,415,395, also assigned to the same assignee of the present invention, discloses system and method for analyzing new fault log data from a malfunctioning machine in which the system and method are not restricted to sequential occurrences of fault log entries, and wherein the system and method predict one or more repair actions using predetermined weighted repair and distinct fault cluster combinations.
Additionally, U.S. Patent No. 6,336,065, assigned to the: same assignee of the present invention, provides system and method that uses snapshot observations of operational parameters from the machine in combination with the fault log data in order to further enhance the predictive accuracy of the diagnostic algorithms used therein.
That invention further provides noise reduction filters, to substantially eliminate undesirable noise, e.g., unreliable or useless information that may be present in the fault log data andlor the operational parameter data.
It is believed that the inventive concepts disclosed in the foregoing patents provide substantial advantages and advancements in the art of computerized diagnostics.
However, the case-based reasoning tools described in the foregoing patents generally rely on associating probabilistic outcomes with individual features of a given case.
The calculation of these probabilistic outcomes may be somewhat time consuming, as may be identification of relevant features within a new case.. In addition, not all features have the same amount of reliability and history associated with them, and calculating their probabilistic relevance based on limited data could lead to inaccurate outcomes.
BRIEF SUMMARY OF THE INVENTION
To address the issues identified in the background section of the present invention, as well as introduce improved diagnostics functionality in a~ diagnostics systems, such as a case-based reasoning system, it is desired to provide an improved algorithm that does not rely on limited case features but on a composition of an entire sample of historical cases. Accordingly, it would be desirable to determine a degree of similarity for a new diagnostics case relative to a broad spectrum of cases.
It would be further desirable to provide improved accuracy at a repair code level (as well as a recommendation level) in order to assign an improved confidence value to a diagnostics solution.
Generally, the present invention fulfills the foregoing needs by providing in one aspect thereof, a method for processing a new diagnostics case relative to historical case data for a machine undergoing diagnostics. The method allows providing a database storing historical case data for the machine undergoing diagnostics.
The method further allows calculating a degree of similarity between the new case and respective cases stored in the database. A list of neighboring cases is determined relative to the new case based on the calculated degree of similarity between the new case and the respective cases stored in the database. The list of neighboring cases is processed to determine a ranking for possible corrective actions for the new case. A
corrective action is selected for the new case based on the ranking of the possible corrective actions for the new case.
However, the case-based reasoning tools described in the foregoing patents generally rely on associating probabilistic outcomes with individual features of a given case.
The calculation of these probabilistic outcomes may be somewhat time consuming, as may be identification of relevant features within a new case.. In addition, not all features have the same amount of reliability and history associated with them, and calculating their probabilistic relevance based on limited data could lead to inaccurate outcomes.
BRIEF SUMMARY OF THE INVENTION
To address the issues identified in the background section of the present invention, as well as introduce improved diagnostics functionality in a~ diagnostics systems, such as a case-based reasoning system, it is desired to provide an improved algorithm that does not rely on limited case features but on a composition of an entire sample of historical cases. Accordingly, it would be desirable to determine a degree of similarity for a new diagnostics case relative to a broad spectrum of cases.
It would be further desirable to provide improved accuracy at a repair code level (as well as a recommendation level) in order to assign an improved confidence value to a diagnostics solution.
Generally, the present invention fulfills the foregoing needs by providing in one aspect thereof, a method for processing a new diagnostics case relative to historical case data for a machine undergoing diagnostics. The method allows providing a database storing historical case data for the machine undergoing diagnostics.
The method further allows calculating a degree of similarity between the new case and respective cases stored in the database. A list of neighboring cases is determined relative to the new case based on the calculated degree of similarity between the new case and the respective cases stored in the database. The list of neighboring cases is processed to determine a ranking for possible corrective actions for the new case. A
corrective action is selected for the new case based on the ranking of the possible corrective actions for the new case.
In another aspect thereof, the present invention further fulfills the foregoing needs by providing a system for processing a new diagnostics case relative to historical case data for a machine undergoing diagnostics. The system includes a database for storing historical case data for the machine undergoing diagnostics. A
processor may be configured to calculate a degree of similarity between the new case and respective cases stored in the database. A processor may be configured to determine a list of neighboring cases relative to the new case based on the calculated degree of similarity between the new case and the respective cases stored in the database. A
processor may be configured to process the list of neighboring cases to determine a ranking for possible corrective actions for the new case, wherein the system allows selecting a corrective action for the new case based on the ranking of the possible corrective actions for the new case. The foregoing processors may comprise modules in a single processor device or may comprise separate processors.
BRIEF DESCRIPTION OF THE DRAWINGS
The features and advantages of the present invention will become apparent from the following detailed description of the invention when read with the accompanying drawings in which:
FIG. 1 is a block diagram of an exemplary diagnostics system embodying aspects of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a block diagram of an exemplary system embodying aspects of the present invention for processing a new diagnostics case relative to historical case data and determine a ranking (e.g., a relative ranking) for possible repairs. As used herein, a case generally refers to a problem/solution description pair that represents a diagnosis of a problem and an appropriate repair.
A processor 10 is coupled to a database 12 that may comprise a plurality of cases applicable to a machine undergoing diagnostics. For example, a plurality of historical cases for a given type of locomotives. In one exemplary embodiment, the processor includes a module 14 configured to calculate a similarity function.
processor may be configured to calculate a degree of similarity between the new case and respective cases stored in the database. A processor may be configured to determine a list of neighboring cases relative to the new case based on the calculated degree of similarity between the new case and the respective cases stored in the database. A
processor may be configured to process the list of neighboring cases to determine a ranking for possible corrective actions for the new case, wherein the system allows selecting a corrective action for the new case based on the ranking of the possible corrective actions for the new case. The foregoing processors may comprise modules in a single processor device or may comprise separate processors.
BRIEF DESCRIPTION OF THE DRAWINGS
The features and advantages of the present invention will become apparent from the following detailed description of the invention when read with the accompanying drawings in which:
FIG. 1 is a block diagram of an exemplary diagnostics system embodying aspects of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a block diagram of an exemplary system embodying aspects of the present invention for processing a new diagnostics case relative to historical case data and determine a ranking (e.g., a relative ranking) for possible repairs. As used herein, a case generally refers to a problem/solution description pair that represents a diagnosis of a problem and an appropriate repair.
A processor 10 is coupled to a database 12 that may comprise a plurality of cases applicable to a machine undergoing diagnostics. For example, a plurality of historical cases for a given type of locomotives. In one exemplary embodiment, the processor includes a module 14 configured to calculate a similarity function.
Exemplary diagnostic cases stored in database 12 may 'be arranged as represented in Table 1 below:
Faults Operational Parameters CaseID
A 73 IMC 13.23443 2 165.152 O 400 3081651683 133705.28 B 73 IMC 13.23443 2 163.682 0 403 30316516_83 133705.28 C 73 IMC 13.25455 2 162.62 0 403 30116516B3 133705.28 Table 1 A new case received for diagnostics analysis could be as represented in Table below:
D 73IMC 13.2344312 163.682 0 403 3031651683 133705.28 E 73IMC 13,254552 162,62 0 403 30i1651683 133705.28 __ F 70CTS 0 0 1 0 O 0 0 0 62 62 0 134250.36 Table 2 Generally, the objective of the similarity function is to arrive at some indication (e.g., a number, alphanumeric code, linguistic label, etc.) indicative of the degree of similarity between any two cases. Assuming a numerical indication, the value of the number indicating the degree of similarity between two cases may conceptually range from 0 to 1, where a zero value would indicate that the two cases are completely different and a unity value would indicate that they are identical. In one exemplary embodiment, the similarity function may operate as follov~s:
Let us introduce a parameter ~, that influences how much importance is given to the frequency or repetition of a fault commonly shared by the two cases that are being matched or compared. If the value of the parameter 7~=l., this would indicate that the frequency of a fault is not considered at all while calculating a similarity match between the two cases. For example, fault 73 may occur 2 times in a first case and 20 times in a second case. Assuming 7~=l, then the contribution of fault 73 to the degree of similarity would be 100% since in this example one would simply determine that the same fault 73 occurred in both cases.
However, if ~=0, the degree of similarity would be entirely dependent on the frequency of fault matching between the two cases. Assuming ~,=1, then, in the foregoing example, the degree of similarity contributed by fault 73 would be 2/20 =
0.1, or 10%.
In one exemplary embodiment, an appropriate choice for the value of ~, may be determined through experiments and/or simulations configured to maximize the performance of the similarity function algorithm for any given application. As stated above, the value of ~, may be as follows: ~, E {0,1 }
Let us say there are two cases Case 1 Case 2 Faults Frequency Faults Frequency A question that may arise may be - what is the degree of similarity between Case 1 and Case 2.
If one were to ignore the frequency column altogether, the information conveyed by the cases might appear as follows:
Case 1 Case 2 Faults Faults The number of common faults = Sum = 2. Eq. (:~) Number of distinct faults in Case 1 = 2 Number of distinct faults in Case2 = 2 Therefore, based on the foregoing assumptions, the degree of similarity for this situation could be calculated as follows:
Degree of similarity = [Number of common favts] z / { [Number of distinct faults in Case 1 ] * [ Number of distinct faults in Case2] ~ = 1 If one were to consider the frequency column to be a substantial factor for calculating the degree of similarity for the same two cases, the information from these two cases may be evaluated as follows:
Case 1 Case 2 Faults Frequency Faults Frequency Fl 10 F1 1 For this situation, the degree of similarity contributed by fault F 1 = 1 /10 = 0.1 and the degree of similarity contributed by fault F2 = 1/10 = 0.1 One may use this information to modify or adjust the original sum calculation in Eq.
(1) above. The original sum calculation was:
Sum = 2 = 1(Fl) + 1(F2) One may adjust the contribution of each shared fault based on its respective degree of similarity taking into account information from the frequency column. The adjusted calculation becomes, Sum = 0.2 = 0.1 (F 1 ) + 0.1 (F2).
The foregoing exemplary calculations should illustrate that the value of Sum for determining the value of the similarity function for these straightforward examples can vary between 0.2 and 2, depending on whether or not one chooses to consider to a full extent the frequency of occurrence of common faults in the two cases being compared.
Let us introduce the parameter a, which allows one to quantitatively modulate or calibrate the effect of fault frequency somewhere between the two diametrically opposite situations described above. That is, either ignoring fault frequency or fully considering fault frequency.
Let Sum = a + (1-a)*Similarity based on Frequency.
In the foregoing example, if the value of parameter a = 0.7, then Sum = [ 0.7 + 0.3*0.1](F1) + [ 0.7 + 0.3'0.1](F2) = 1.46 For a general situation, let us assume the ith case Ci comprises a plurality of faults Fi, let us further assume the jith case Cj comprises a plurality of faults Fj:
For each fault Fi in {Ci U Cj }, If Fi E {Ci} & EFi {Cj} then sum - a + (1-a)*{ [ Min ( count(Fi), count(Fj)]/[Max ( count(Fi), count(Fj) ]}
a) Similarity S = [sum]
Count[ {Fi} ]XCount[ {Fj} ]
Where Count(Fi) is the number of distinct faults in the ith Case, and Count(Fj) is the number of distinct faults in the jth Case.
This would result in an output (e.g., ordered listing) of all cases that have non-zero similarity (or at least have a similarity numerical value above a preset threshold value) relative to a new case (e.g., a 'probecase'). An example of such an output may be as shown in Table 3 below, where each case happens to have the same degree of similarity relative to the probecase.
Recommendation Code Repair Code Probecase . C53 9109 1989 Cables, Terminals - Traction Motor Neighbors 37.0% 95 9109 1867 TM1 - Traction Motor (AC) 37.0% 95 9109 1868 TM2 - Traction Motor (AC) 37.0% 95 9109 1869 TM3 - Traction Motor (AC) 37.0% C000953 9109 1871 TM5 - Traction Motor (A.C) 37.0% C000953 9109 1870 TM4 - Traction Motor (AC) Table 3 b) Ranking function:
In one exemplary embodiment, processor 10 further includes a module 16 for synthesizing the plurality of neighboring cases from the similarity function module 14 into a ranked output of cases (e.g., a relative ranking of cases). Since, in general, the output of the similarity function module is a list of neighboring cases, it is plausible that at least some of these cases may have the same repair code or recommendation associated with them. This is especially true if the new case is of a type that is frequently observed or detected. An example of such an output exhibiting cases with varying degrees of similarity is shown below in Table 4.
Before Rollup Probecase : 132 185 1681 SS6 - Traction Motor Speed Sensor 6 Neighbors 100.0 1345 185 1681 SS6 - TractionMotor_Speed Sensor 100.0 1788 185 1681 SS6 - TractionMotor Speed Sensor 100.0 1820 185 1681 SS6 - TractionMotor Speed Sensor 100.0 2990 185 1681 SS6 - TractionMotor_Speed Sensor 8l.Oo 1705 53031520 CGS - Air Compressor Switc h 60.Oo 1915 185 1681 SS6 Traction Motor Speed Sensor -57.Oo 2560 185 1681 SS6 Traction N~otorSpeed Sensor -56.Oo 0715 185 1681 SS6 Traction Motor Speed Sensor -56.Oo 2944 185 1681 SS6 Traction Motor Speed Sensor -50.Oo 2312 185 1681 SS6 Traction Motor Speed Sensor -50.Oo 2882 185 1681 SS6 Traction Motor Speed Sensor -50.Oo 2905 185 1872 TM6 Traction Motor (AC) -33.Oo 1179 185 1681 SS6 Traction Mator Speed Sensor -32.Oo 4284 185 1681 SS6 Traction Motor Speed Sensor -Table 4 In order to process the output from the similarity function module 14 into one that selectively categorizes distinct diagnoses, one may use a ranking function, also colloquially referred to as a "rollup function." The basic concept behind the rollup function is to perform a discounted voting solution to condense multiple cases pointing to the same diagnosis and boost their relative rank up and associate a more statistically meaningful confidence level for such cases. Since the voting is aggregated, it is possible that a final aggregated result for a given case may be greater than 100%. This may mean that the new case not only matches one single archived case, but also matches well with many archived cases. See, for example, Table 5 that includes an exemplary listing condensing the rankings for the distinct diagnosis identified in Table 4.
After Rollup 285.00 1345 185 1681 SS6 - Traction Motor Speed Sensor 6 8l.Oo 1705 5303 1520 CGS - Air Compressor Gov Press Switch 50.Oo 2905 185 1872 TM6 - Traction Motor (AC) Table 5 In one exemplary embodiment, the rollup algorithm may comprise the following instructions:
Rci = repair code for case at ranking i.
Mi = Match percentage for case at rank i.
N = total number of neighbor cases.
/3 = damping factor For(i=l;i<n;i++) {for (j = i+l;j<=nj++)}
{if( (Rci = Rcj) and Neighbor j is not disabled)}
{Mi = Mi + 1/(j-i+/.3 ) * Mj; Disable Neighbor j }
The same process can be repeated for assessing the ranking by recommendations in lieu of repair code.
Intuitive plain English explanation of the rollup function:
There are at least two basic ways for a recommendation to climb (or to "rollup") to the top of the list. The first would be to have a very high match percentage, indicating that there is an excellent match. See for example in Table 4 the recommendations with 100 percent match. However, this begs the question: What does one do in situations when one has to decide, for example, between a single recommendation Rl with a relatively high numerical match (e.g., a 0.9 match) and several recommendations with a relatively lower numerical match (e.g., 10 matched recommendations of type R2 with a 0.75 match)? One would want to integrate this information and provide a combined or partial credit for these types of situations.
That is, one would like to quantitatively account for a broad spectrum of situations, such as a) situations with relatively high numerical match with one (or just a few) recommendations, and b) situations with a relatively lower numerical match but with a relatively large number of past occurrences. That is, situations with a relatively lower numerical match yet based on substantial precedential value from previous cases. This combined crediting is what the rollup function is configured to perform.
Let us assume a raw match output as in Table 6 below:
Table 6 Rank Recommendation Degree of l~~Iatch 1 Rl 0.71 2 R2 0.7 3 R3 0.5 4 R4 0.4 One would want to reflect the fact that recommendation R2 is found twice (e.g., at Ranks 2 and 4), and thus give recommendation R2 credit for that fact. In this example, one may perform this adjustment by combining with the Degree of Match of repair R2 at Rank 2, the degree of match of repair RZ at Rank 4, reduced by a discounting factor. In this example, this factor would be 1 / (difference in ranks +
degree of damping).
Assuming the degree of damping is 3, then the computation of the combined relative ranking becomes l/(4-2+3)=0.20 So the degree of match of R2 at rank2 will be updated as = 0.7 + (0.20)*(0.4) = 0.78 While the preferred embodiments of the present invention have been shown and described herein, it will be obvious that such embodiments are provided by way of example only. Numerous variations, changes and substitutions will occur to those of skill in the art without departing from the invention herein. Accordingly, it is intended that the invention be limited only by the spirit and scope of the appended claims.
Faults Operational Parameters CaseID
A 73 IMC 13.23443 2 165.152 O 400 3081651683 133705.28 B 73 IMC 13.23443 2 163.682 0 403 30316516_83 133705.28 C 73 IMC 13.25455 2 162.62 0 403 30116516B3 133705.28 Table 1 A new case received for diagnostics analysis could be as represented in Table below:
D 73IMC 13.2344312 163.682 0 403 3031651683 133705.28 E 73IMC 13,254552 162,62 0 403 30i1651683 133705.28 __ F 70CTS 0 0 1 0 O 0 0 0 62 62 0 134250.36 Table 2 Generally, the objective of the similarity function is to arrive at some indication (e.g., a number, alphanumeric code, linguistic label, etc.) indicative of the degree of similarity between any two cases. Assuming a numerical indication, the value of the number indicating the degree of similarity between two cases may conceptually range from 0 to 1, where a zero value would indicate that the two cases are completely different and a unity value would indicate that they are identical. In one exemplary embodiment, the similarity function may operate as follov~s:
Let us introduce a parameter ~, that influences how much importance is given to the frequency or repetition of a fault commonly shared by the two cases that are being matched or compared. If the value of the parameter 7~=l., this would indicate that the frequency of a fault is not considered at all while calculating a similarity match between the two cases. For example, fault 73 may occur 2 times in a first case and 20 times in a second case. Assuming 7~=l, then the contribution of fault 73 to the degree of similarity would be 100% since in this example one would simply determine that the same fault 73 occurred in both cases.
However, if ~=0, the degree of similarity would be entirely dependent on the frequency of fault matching between the two cases. Assuming ~,=1, then, in the foregoing example, the degree of similarity contributed by fault 73 would be 2/20 =
0.1, or 10%.
In one exemplary embodiment, an appropriate choice for the value of ~, may be determined through experiments and/or simulations configured to maximize the performance of the similarity function algorithm for any given application. As stated above, the value of ~, may be as follows: ~, E {0,1 }
Let us say there are two cases Case 1 Case 2 Faults Frequency Faults Frequency A question that may arise may be - what is the degree of similarity between Case 1 and Case 2.
If one were to ignore the frequency column altogether, the information conveyed by the cases might appear as follows:
Case 1 Case 2 Faults Faults The number of common faults = Sum = 2. Eq. (:~) Number of distinct faults in Case 1 = 2 Number of distinct faults in Case2 = 2 Therefore, based on the foregoing assumptions, the degree of similarity for this situation could be calculated as follows:
Degree of similarity = [Number of common favts] z / { [Number of distinct faults in Case 1 ] * [ Number of distinct faults in Case2] ~ = 1 If one were to consider the frequency column to be a substantial factor for calculating the degree of similarity for the same two cases, the information from these two cases may be evaluated as follows:
Case 1 Case 2 Faults Frequency Faults Frequency Fl 10 F1 1 For this situation, the degree of similarity contributed by fault F 1 = 1 /10 = 0.1 and the degree of similarity contributed by fault F2 = 1/10 = 0.1 One may use this information to modify or adjust the original sum calculation in Eq.
(1) above. The original sum calculation was:
Sum = 2 = 1(Fl) + 1(F2) One may adjust the contribution of each shared fault based on its respective degree of similarity taking into account information from the frequency column. The adjusted calculation becomes, Sum = 0.2 = 0.1 (F 1 ) + 0.1 (F2).
The foregoing exemplary calculations should illustrate that the value of Sum for determining the value of the similarity function for these straightforward examples can vary between 0.2 and 2, depending on whether or not one chooses to consider to a full extent the frequency of occurrence of common faults in the two cases being compared.
Let us introduce the parameter a, which allows one to quantitatively modulate or calibrate the effect of fault frequency somewhere between the two diametrically opposite situations described above. That is, either ignoring fault frequency or fully considering fault frequency.
Let Sum = a + (1-a)*Similarity based on Frequency.
In the foregoing example, if the value of parameter a = 0.7, then Sum = [ 0.7 + 0.3*0.1](F1) + [ 0.7 + 0.3'0.1](F2) = 1.46 For a general situation, let us assume the ith case Ci comprises a plurality of faults Fi, let us further assume the jith case Cj comprises a plurality of faults Fj:
For each fault Fi in {Ci U Cj }, If Fi E {Ci} & EFi {Cj} then sum - a + (1-a)*{ [ Min ( count(Fi), count(Fj)]/[Max ( count(Fi), count(Fj) ]}
a) Similarity S = [sum]
Count[ {Fi} ]XCount[ {Fj} ]
Where Count(Fi) is the number of distinct faults in the ith Case, and Count(Fj) is the number of distinct faults in the jth Case.
This would result in an output (e.g., ordered listing) of all cases that have non-zero similarity (or at least have a similarity numerical value above a preset threshold value) relative to a new case (e.g., a 'probecase'). An example of such an output may be as shown in Table 3 below, where each case happens to have the same degree of similarity relative to the probecase.
Recommendation Code Repair Code Probecase . C53 9109 1989 Cables, Terminals - Traction Motor Neighbors 37.0% 95 9109 1867 TM1 - Traction Motor (AC) 37.0% 95 9109 1868 TM2 - Traction Motor (AC) 37.0% 95 9109 1869 TM3 - Traction Motor (AC) 37.0% C000953 9109 1871 TM5 - Traction Motor (A.C) 37.0% C000953 9109 1870 TM4 - Traction Motor (AC) Table 3 b) Ranking function:
In one exemplary embodiment, processor 10 further includes a module 16 for synthesizing the plurality of neighboring cases from the similarity function module 14 into a ranked output of cases (e.g., a relative ranking of cases). Since, in general, the output of the similarity function module is a list of neighboring cases, it is plausible that at least some of these cases may have the same repair code or recommendation associated with them. This is especially true if the new case is of a type that is frequently observed or detected. An example of such an output exhibiting cases with varying degrees of similarity is shown below in Table 4.
Before Rollup Probecase : 132 185 1681 SS6 - Traction Motor Speed Sensor 6 Neighbors 100.0 1345 185 1681 SS6 - TractionMotor_Speed Sensor 100.0 1788 185 1681 SS6 - TractionMotor Speed Sensor 100.0 1820 185 1681 SS6 - TractionMotor Speed Sensor 100.0 2990 185 1681 SS6 - TractionMotor_Speed Sensor 8l.Oo 1705 53031520 CGS - Air Compressor Switc h 60.Oo 1915 185 1681 SS6 Traction Motor Speed Sensor -57.Oo 2560 185 1681 SS6 Traction N~otorSpeed Sensor -56.Oo 0715 185 1681 SS6 Traction Motor Speed Sensor -56.Oo 2944 185 1681 SS6 Traction Motor Speed Sensor -50.Oo 2312 185 1681 SS6 Traction Motor Speed Sensor -50.Oo 2882 185 1681 SS6 Traction Motor Speed Sensor -50.Oo 2905 185 1872 TM6 Traction Motor (AC) -33.Oo 1179 185 1681 SS6 Traction Mator Speed Sensor -32.Oo 4284 185 1681 SS6 Traction Motor Speed Sensor -Table 4 In order to process the output from the similarity function module 14 into one that selectively categorizes distinct diagnoses, one may use a ranking function, also colloquially referred to as a "rollup function." The basic concept behind the rollup function is to perform a discounted voting solution to condense multiple cases pointing to the same diagnosis and boost their relative rank up and associate a more statistically meaningful confidence level for such cases. Since the voting is aggregated, it is possible that a final aggregated result for a given case may be greater than 100%. This may mean that the new case not only matches one single archived case, but also matches well with many archived cases. See, for example, Table 5 that includes an exemplary listing condensing the rankings for the distinct diagnosis identified in Table 4.
After Rollup 285.00 1345 185 1681 SS6 - Traction Motor Speed Sensor 6 8l.Oo 1705 5303 1520 CGS - Air Compressor Gov Press Switch 50.Oo 2905 185 1872 TM6 - Traction Motor (AC) Table 5 In one exemplary embodiment, the rollup algorithm may comprise the following instructions:
Rci = repair code for case at ranking i.
Mi = Match percentage for case at rank i.
N = total number of neighbor cases.
/3 = damping factor For(i=l;i<n;i++) {for (j = i+l;j<=nj++)}
{if( (Rci = Rcj) and Neighbor j is not disabled)}
{Mi = Mi + 1/(j-i+/.3 ) * Mj; Disable Neighbor j }
The same process can be repeated for assessing the ranking by recommendations in lieu of repair code.
Intuitive plain English explanation of the rollup function:
There are at least two basic ways for a recommendation to climb (or to "rollup") to the top of the list. The first would be to have a very high match percentage, indicating that there is an excellent match. See for example in Table 4 the recommendations with 100 percent match. However, this begs the question: What does one do in situations when one has to decide, for example, between a single recommendation Rl with a relatively high numerical match (e.g., a 0.9 match) and several recommendations with a relatively lower numerical match (e.g., 10 matched recommendations of type R2 with a 0.75 match)? One would want to integrate this information and provide a combined or partial credit for these types of situations.
That is, one would like to quantitatively account for a broad spectrum of situations, such as a) situations with relatively high numerical match with one (or just a few) recommendations, and b) situations with a relatively lower numerical match but with a relatively large number of past occurrences. That is, situations with a relatively lower numerical match yet based on substantial precedential value from previous cases. This combined crediting is what the rollup function is configured to perform.
Let us assume a raw match output as in Table 6 below:
Table 6 Rank Recommendation Degree of l~~Iatch 1 Rl 0.71 2 R2 0.7 3 R3 0.5 4 R4 0.4 One would want to reflect the fact that recommendation R2 is found twice (e.g., at Ranks 2 and 4), and thus give recommendation R2 credit for that fact. In this example, one may perform this adjustment by combining with the Degree of Match of repair R2 at Rank 2, the degree of match of repair RZ at Rank 4, reduced by a discounting factor. In this example, this factor would be 1 / (difference in ranks +
degree of damping).
Assuming the degree of damping is 3, then the computation of the combined relative ranking becomes l/(4-2+3)=0.20 So the degree of match of R2 at rank2 will be updated as = 0.7 + (0.20)*(0.4) = 0.78 While the preferred embodiments of the present invention have been shown and described herein, it will be obvious that such embodiments are provided by way of example only. Numerous variations, changes and substitutions will occur to those of skill in the art without departing from the invention herein. Accordingly, it is intended that the invention be limited only by the spirit and scope of the appended claims.
Claims (11)
1. A method for processing a new diagnostics case (e.g., 18) relative to historical case data for a machine undergoing diagnostics, the method comprising:
providing a database 12 storing historical case data for the machine undergoing diagnostics;
calculating (e.g., 14) a degree of similarity between the new case and respective cases stored in the database;
determining a list of neighboring cases relative to the new case based on the calculated degree of similarity between the new case and the respective cases stored in the database;
processing (e.g., 16) the list of neighboring cases to determine a ranking for possible corrective actions for the new case; and selecting a corrective action for the new case based on the ranking of the possible corrective actions for the new case.
providing a database 12 storing historical case data for the machine undergoing diagnostics;
calculating (e.g., 14) a degree of similarity between the new case and respective cases stored in the database;
determining a list of neighboring cases relative to the new case based on the calculated degree of similarity between the new case and the respective cases stored in the database;
processing (e.g., 16) the list of neighboring cases to determine a ranking for possible corrective actions for the new case; and selecting a corrective action for the new case based on the ranking of the possible corrective actions for the new case.
2. The method of claim 1 wherein the degree of similarity is a numerical determination.
3. The method of claim 1 wherein the ranking of the possible corrective actions is a relative ranking among the possible corrective actions.
4. The method of claim 1 wherein the degree of similarity is based, at least in part, on a frequency of occurrence of faults shared in common between the-new case and the respective cases stored in the database.
5. The method of claim 1 wherein the calculated degree of similarity (S) is based on the following equation, wherein if a fault Fi .epsilon. {Ci} & .epsilon.Fi{Cj}, then sum = a + (1- a)*
{[Min( count(Fi), count(Fj)]/[Mix (count(Fi), count(Fj)]}, count(Fi) is a number of distinct faults in the ith Case, and Count(Fj) is a number of distinct faults in the jth case, and a is a parameter having a value between zero and one for weighing a frequency of occurrence of faults shared in common between any two cases whose degree of similarity is being calculated.
{[Min( count(Fi), count(Fj)]/[Mix (count(Fi), count(Fj)]}, count(Fi) is a number of distinct faults in the ith Case, and Count(Fj) is a number of distinct faults in the jth case, and a is a parameter having a value between zero and one for weighing a frequency of occurrence of faults shared in common between any two cases whose degree of similarity is being calculated.
6. The method of claim 1 wherein the ranking for possible corrective actions for the new case is based, at least in part, on a rank difference between respective ones of the possible corrective actions.
7. The method of claim 1 wherein the ranking for possible corrective actions for the new case is based one the following equation for (i = 1; i < n; i=i+1) and for (j = i+1;j<=n; j=j+1), {if((Rci = Rcj)}, then {Mi = Mi + 1/(j-i+.beta.)*Mj}, wherein Rci represents a corrective action for a case at rank i, Rcj represents a corrective action for a case at rank j, Mi represents a match percentage for the case at rank i, Mj represents a match percentage for the case at rank j, N represents a total number of neighboring cases, and .beta. represents a predefined damping factor.
8. A system for processing a new diagnostics case (e.g., 18) relative to historical case data for a machine undergoing diagnostics, the system comprising:
a database 12 storing historical case data for the machine undergoing diagnostics;
a processor (e.g., 14) configured to calculate a degree of similarity between the new case and respective cases stored in the database;
a processor (e.g., 10) configured to determine a list of neighboring cases relative to the new case based on the calculated degree of similarity between the new case and the respective cases stored in the database; and a processor (e.g., 16) configured to process the list of neighboring cases to determine a ranking for possible corrective actions for the new case, wherein the system selects a corrective action for the new case based on the ranking of the possible corrective actions for the new case.
a database 12 storing historical case data for the machine undergoing diagnostics;
a processor (e.g., 14) configured to calculate a degree of similarity between the new case and respective cases stored in the database;
a processor (e.g., 10) configured to determine a list of neighboring cases relative to the new case based on the calculated degree of similarity between the new case and the respective cases stored in the database; and a processor (e.g., 16) configured to process the list of neighboring cases to determine a ranking for possible corrective actions for the new case, wherein the system selects a corrective action for the new case based on the ranking of the possible corrective actions for the new case.
9. The system of claim 8 further comprising a processor configured to calculate a numerical degree of similarity.
10. The system of claim 8 further comprising a processor configured to calculate a relative ranking among the possible corrective actions.
11. The system of claim 8 wherein said processors are modules of a single processor device.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/444,528 | 2003-05-23 | ||
| US10/444,528 US7206965B2 (en) | 2003-05-23 | 2003-05-23 | System and method for processing a new diagnostics case relative to historical case data and determining a ranking for possible repairs |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2467230A1 true CA2467230A1 (en) | 2004-11-23 |
Family
ID=33450682
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002467230A Abandoned CA2467230A1 (en) | 2003-05-23 | 2004-05-13 | System and method for processing a new diagnostics case relative to historical case data and determining a ranking for possible repairs |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7206965B2 (en) |
| AU (1) | AU2004201704A1 (en) |
| CA (1) | CA2467230A1 (en) |
| MX (1) | MXPA04004897A (en) |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7509538B2 (en) * | 2004-04-21 | 2009-03-24 | Microsoft Corporation | Systems and methods for automated classification and analysis of large volumes of test result data |
| EP1703449A1 (en) * | 2005-03-18 | 2006-09-20 | BRITISH TELECOMMUNICATIONS public limited company | Fault diagnostics |
| JP4494330B2 (en) * | 2005-11-28 | 2010-06-30 | 株式会社日立製作所 | Policy control method, apparatus and program |
| US7860818B2 (en) * | 2006-06-29 | 2010-12-28 | Siemens Corporation | System and method for case-based multilabel classification and ranking |
| US7711440B1 (en) | 2006-09-28 | 2010-05-04 | Rockwell Automation Technologies, Inc. | Browser based embedded historian |
| US7672740B1 (en) | 2006-09-28 | 2010-03-02 | Rockwell Automation Technologies, Inc. | Conditional download of data from embedded historians |
| US7742833B1 (en) | 2006-09-28 | 2010-06-22 | Rockwell Automation Technologies, Inc. | Auto discovery of embedded historians in network |
| US8181157B2 (en) | 2006-09-29 | 2012-05-15 | Rockwell Automation Technologies, Inc. | Custom language support for project documentation and editing |
| US7913228B2 (en) * | 2006-09-29 | 2011-03-22 | Rockwell Automation Technologies, Inc. | Translation viewer for project documentation and editing |
| US20080114474A1 (en) * | 2006-11-10 | 2008-05-15 | Rockwell Automation Technologies, Inc. | Event triggered data capture via embedded historians |
| US7933666B2 (en) | 2006-11-10 | 2011-04-26 | Rockwell Automation Technologies, Inc. | Adjustable data collection rate for embedded historians |
| US7974937B2 (en) * | 2007-05-17 | 2011-07-05 | Rockwell Automation Technologies, Inc. | Adaptive embedded historians with aggregator component |
| US7930639B2 (en) * | 2007-09-26 | 2011-04-19 | Rockwell Automation Technologies, Inc. | Contextualization for historians in industrial systems |
| US7917857B2 (en) * | 2007-09-26 | 2011-03-29 | Rockwell Automation Technologies, Inc. | Direct subscription to intelligent I/O module |
| US7930261B2 (en) * | 2007-09-26 | 2011-04-19 | Rockwell Automation Technologies, Inc. | Historians embedded in industrial units |
| US7962440B2 (en) * | 2007-09-27 | 2011-06-14 | Rockwell Automation Technologies, Inc. | Adaptive industrial systems via embedded historian data |
| US7809656B2 (en) * | 2007-09-27 | 2010-10-05 | Rockwell Automation Technologies, Inc. | Microhistorians as proxies for data transfer |
| US7882218B2 (en) * | 2007-09-27 | 2011-02-01 | Rockwell Automation Technologies, Inc. | Platform independent historian |
| US20090089671A1 (en) * | 2007-09-28 | 2009-04-02 | Rockwell Automation Technologies, Inc. | Programmable controller programming with embedded macro capability |
| US7921337B2 (en) * | 2008-05-30 | 2011-04-05 | Honeywell International Inc. | Systems and methods for diagnosing faults in electronic systems |
| US8326789B2 (en) * | 2009-08-20 | 2012-12-04 | Uop Llc | Expert system integrated with remote performance management |
| US20140280065A1 (en) | 2013-03-13 | 2014-09-18 | Salesforce.Com, Inc. | Systems and methods for predictive query implementation and usage in a multi-tenant database system |
| JP6453872B2 (en) * | 2013-07-08 | 2019-01-16 | オーシーティー トリプル インダストリーズ リミティド ライアビリティ カンパニー | System and method for pre-evaluation vehicle diagnosis and repair cost estimation |
| US10311364B2 (en) * | 2013-11-19 | 2019-06-04 | Salesforce.Com, Inc. | Predictive intelligence for service and support |
| US20160063418A1 (en) * | 2014-09-03 | 2016-03-03 | General Electric Company | System and Method for Inferring Vehicle Health |
| US20180096312A1 (en) * | 2016-09-30 | 2018-04-05 | Honeywell International Inc. | System and method for generating and representing a cost optimized diagnostic work plan |
| US10419274B2 (en) * | 2017-12-08 | 2019-09-17 | At&T Intellectual Property I, L.P. | System facilitating prediction, detection and mitigation of network or device issues in communication systems |
| US11741096B1 (en) | 2018-02-05 | 2023-08-29 | Amazon Technologies, Inc. | Granular performance analysis for database queries |
| CN110390415A (en) | 2018-04-18 | 2019-10-29 | 北京嘀嘀无限科技发展有限公司 | A kind of method and system carrying out trip mode recommendation based on user's trip big data |
| US11449516B2 (en) | 2020-11-04 | 2022-09-20 | International Business Machines Corporation | Ranking of documents belonging to different domains based on comparison of descriptors thereof |
| CN113655770A (en) * | 2021-07-02 | 2021-11-16 | 上海乐意修科技有限公司 | Automobile fault diagnosis teaching system and method |
| CN113907721A (en) * | 2021-09-30 | 2022-01-11 | 北京电子科技职业学院 | Cardiovascular disease auxiliary diagnosis system based on case reasoning |
| US11789842B2 (en) * | 2021-10-11 | 2023-10-17 | Dell Products L.P. | System and method for advanced detection of potential system impairment |
| US20230129123A1 (en) * | 2021-10-26 | 2023-04-27 | Dell Products L.P. | Monitoring and Management System for Automatically Generating an Issue Prediction for a Trouble Ticket |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5293323A (en) | 1991-10-24 | 1994-03-08 | General Electric Company | Method for fault diagnosis by assessment of confidence measure |
| US5463768A (en) * | 1994-03-17 | 1995-10-31 | General Electric Company | Method and system for analyzing error logs for diagnostics |
| US6175934B1 (en) | 1997-12-15 | 2001-01-16 | General Electric Company | Method and apparatus for enhanced service quality through remote diagnostics |
| US6473659B1 (en) * | 1998-04-10 | 2002-10-29 | General Electric Company | System and method for integrating a plurality of diagnostic related information |
| JP4025443B2 (en) * | 1998-12-04 | 2007-12-19 | 富士通株式会社 | Document data providing apparatus and document data providing method |
| US6941321B2 (en) * | 1999-01-26 | 2005-09-06 | Xerox Corporation | System and method for identifying similarities among objects in a collection |
| US6415395B1 (en) | 1999-04-02 | 2002-07-02 | General Electric Company | Method and system for processing repair data and fault log data to facilitate diagnostics |
| US6336065B1 (en) | 1999-10-28 | 2002-01-01 | General Electric Company | Method and system for analyzing fault and snapshot operational parameter data for diagnostics of machine malfunctions |
| US6343236B1 (en) | 1999-04-02 | 2002-01-29 | General Electric Company | Method and system for analyzing fault log data for diagnostics |
| US6853389B1 (en) * | 1999-04-26 | 2005-02-08 | Canon Kabushiki Kaisha | Information searching apparatus, information searching method, and storage medium |
| US6442542B1 (en) * | 1999-10-08 | 2002-08-27 | General Electric Company | Diagnostic system with learning capabilities |
| WO2001031514A2 (en) | 1999-10-28 | 2001-05-03 | General Electric Company | A process for the monitoring and diagnostics of data from a remote asset |
| US6543007B1 (en) | 1999-10-28 | 2003-04-01 | General Electric Company | Process and system for configuring repair codes for diagnostics of machine malfunctions |
| US6405108B1 (en) | 1999-10-28 | 2002-06-11 | General Electric Company | Process and system for developing predictive diagnostics algorithms in a machine |
| US6324659B1 (en) | 1999-10-28 | 2001-11-27 | General Electric Company | Method and system for identifying critical faults in machines |
| US6917936B2 (en) * | 2002-12-18 | 2005-07-12 | Xerox Corporation | Method and apparatus for measuring similarity between documents |
| US7490116B2 (en) * | 2003-01-23 | 2009-02-10 | Verdasys, Inc. | Identifying history of modification within large collections of unstructured data |
-
2003
- 2003-05-23 US US10/444,528 patent/US7206965B2/en not_active Expired - Fee Related
-
2004
- 2004-04-22 AU AU2004201704A patent/AU2004201704A1/en not_active Abandoned
- 2004-05-13 CA CA002467230A patent/CA2467230A1/en not_active Abandoned
- 2004-05-21 MX MXPA04004897A patent/MXPA04004897A/en active IP Right Grant
Also Published As
| Publication number | Publication date |
|---|---|
| MXPA04004897A (en) | 2005-09-30 |
| US20040250163A1 (en) | 2004-12-09 |
| AU2004201704A1 (en) | 2004-12-09 |
| US7206965B2 (en) | 2007-04-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7206965B2 (en) | System and method for processing a new diagnostics case relative to historical case data and determining a ranking for possible repairs | |
| US6650949B1 (en) | Method and system for sorting incident log data from a plurality of machines | |
| US6415395B1 (en) | Method and system for processing repair data and fault log data to facilitate diagnostics | |
| Mosallam et al. | Data-driven prognostic method based on Bayesian approaches for direct remaining useful life prediction | |
| US20200371858A1 (en) | Fault Predicting System and Fault Prediction Method | |
| CN107111311B (en) | Gas turbine sensor fault detection using sparse coding methods | |
| US6871160B2 (en) | Intelligent condition-based engine/equipment management system | |
| AU781329B2 (en) | Method and system for analyzing continuous parameter data for diagnostics and repairs | |
| Vachtsevanos et al. | Fault prognosis using dynamic wavelet neural networks | |
| US6625589B1 (en) | Method for adaptive threshold computation for time and frequency based anomalous feature identification in fault log data | |
| US5463768A (en) | Method and system for analyzing error logs for diagnostics | |
| US20070220368A1 (en) | Data-centric monitoring method | |
| US20040049715A1 (en) | Computer networked intelligent condition-based engine/equipment management system | |
| US20040078099A1 (en) | Method and system for analyzing operational parameter data for diagnostics and repairs | |
| US20030208706A1 (en) | Method and system for analyzing fault and quantized operational data for automated diagnostics of locomotives | |
| US20110307743A1 (en) | False alarm mitigation | |
| MXPA04006254A (en) | Method, system and computer product for estimating a remaining equipment life. | |
| KR102444442B1 (en) | System and method for diagnosing facility fault | |
| EP2410312A1 (en) | A method for computer-assisted analyzing of a technical system | |
| US20090265134A1 (en) | Benchmarking diagnostic algorithms | |
| Saha et al. | Integrated economic design of quality control and maintenance management: Implications for managing manufacturing process | |
| CN113111591A (en) | Automatic diagnosis method, device and equipment based on internal fault of modular power distribution terminal | |
| Calabrese et al. | An event based machine learning framework for predictive maintenance in industry 4.0 | |
| Singh et al. | Trends in the development of system-level fault dependency matrices | |
| Challagulla et al. | A unified framework for defect data analysis using the mbr technique |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |