Method and system for sorting incident log data from a plurality of machines

[0002] This application claims the benefit of provisional application Ser. No. 60/173,948 filed Dec. 30, 1999.

[0003] The present invention relates generally to machine diagnostics, and more specifically, to a system and method for sorting machine data, e.g., operational parameter data and incident log data to facilitate analysis of one or more machines undergoing diagnostics.

[0004] 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.

[0005] 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.

[0006] 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 little pre-processing of raw knowledge, focusing instead on indexing, retrieval, reuse, and archival of cases. In the diagnostic context, a case refers to a problem/solution description pair that represents a diagnosis of a problem and an appropriate repair.

[0007] 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.

[0008] U.S. Pat. No. 5,463,768 discloses an approach which 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 are 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.

[0009] U.S. Pat. No. 6,343,236, assigned to the same assignee of the present invention and herein incorporated by reference, discloses a 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. Pat. No. 6,415,395, assigned to the same assignee of the present invention and herein incorporated by reference, discloses a 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.

[0010] It is believed that the diagnostic tools disclosed in the foregoing patent applications provide substantial advantages and advancements in the art of diagnostics. It would be desirable, however, to provide a system and method that allows for sorting the incident log data based on the severity of the incident so that incidents likely to result in a mission failure, e.g., a road failure in the case of a locomotive, are prioritized over incidents not likely to affect machine operation, at least for a predetermined period of time. It would be further desirable, through the use of incident-authentication rules, to substantially eliminate nuisance incidents, e.g., incidents containing unreliable or useless information that may be present in the incident log data and/or the operational parameter data. This sorting or triage process would advantageously allow for increasing the probability of early detection of actual incipient failures in the machine, as well as decreasing the probability of falsely declaring non-existent failures. Further, such incident-authentication rules would prevent feeding the nuisance incidents into the diagnostic tools and would thus further enhance the predictive accuracy of the diagnostic algorithms used therein while conserving the processing power consumed by the diagnostic algorithms.

[0011] Generally speaking, one embodiment of the present invention fulfills the foregoing needs by providing a method for sorting respective incident log data from a plurality of machines undergoing diagnostics. The method allows for receiving incident log data comprising one or more incidents from the plurality of machines. The method further allows for assigning a predetermined incident severity rating to the respective incidents and for processing the respective incidents based on their respective incident severity rating.

[0012] Another embodiment of the present invention further fulfills the foregoing needs by providing a method for sorting respective incident log data from a plurality of machines undergoing diagnostics. The method allows for receiving incident log data comprising one or more incidents from the plurality of machines and for receiving operational parameter data from the plurality of machines. The method further allows for executing a set of incident-authentication rules indicative of whether a received incident actually corresponds to a faulty condition or not. An assigning step allows for assigning a predetermined incident severity rating to the respective incidents, and a processing step allows for processing the respective incidents based on their respective incident severity rating.

[0013] The present invention further provides a system for sorting respective incident log data from a plurality of machines undergoing diagnostics. The system includes means for receiving incident log data comprising one or more incidents from the plurality of machines. The system further includes means for assigning a predetermined incident severity rating to the respective incidents, and means for processing the respective incidents based on their respective incident severity rating.

[0014] 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:

[0015] FIG. 1 is a block diagram schematic of an exemplary diagnostic system that may be coupled to receive incident log data from a triage or sorting processor embodying the present invention;

[0016] FIG. 2 is an illustration of a portion of exemplary repair log data;

[0017] FIG. 3 is an illustration of a portion of exemplary machine data, e.g., incident log data, operational parameter data, etc.

[0018] FIG. 4 is a flow chart of one exemplary embodiment of the sorting process of the present invention;

[0019] FIG. 5 is a flow chart of another exemplary embodiment of the sorting process of the present invention; and

[0020] FIG. 6 shows exemplary incident-authentication rules.

[0021] FIG. 1 diagrammatically illustrates one exemplary diagnostic system 10 that may benefit from the techniques of the present invention. System 10 provides a process for automatically harvesting or mining repair data comprising a plurality of related and unrelated repairs and incident log data comprising a plurality of incidents, from one or more machines such as locomotives, and generating weighted repair and distinct incident cluster combinations which are diagnostically significant predictors to facilitate analysis of new incident log data from a malfunctioning locomotive. As used herein incident log data refers to machine log data that may comprise fault-type indications of an impending malfunction in one or more subsystems of the locomotive, and may further comprise non-critical informational-type indications that may not require any corrective action and may be useful to corroborate the health status of one or more of the subsystems of the machine.

[0022] Although the present invention is described with reference to a locomotive, the techniques of the present invention can be used in conjunction with any machine in which operation of the machine is monitored, such as a chemical, an electronic, a mechanical, or a microprocessor machine.

[0023] Exemplary system 10 includes a diagnostic processor 12 such as a computer (e.g., UNIX workstation) having a hard drive, input devices such as a keyboard, a mouse, magnetic storage media (e.g., tape cartridges or disks), optical storage media (e.g., CD-ROMs), and output devices such as a display and a printer. Processor 12 is operably connected to and processes data contained in a repair data storage unit 20 and an incident log data storage unit 22. In one aspect of this invention processor 12 is further respectively connected to a sorting or triage processor 14 that executes incident-authentication filters stored in a storage unit.

[0024] Repair data storage unit 20 includes repair data or records regarding a plurality of related and unrelated repairs for one or more locomotives. FIG. 2 shows an exemplary portion 30 of the repair data contained in repair data storage unit 20. The repair data may include a customer identification number 32, a locomotive identification or unit number 33, the date 34 of the repair, the repair code 35, a repair code description 36, a description of the actual repair 37 performed, etc.

[0025] Incident log data storage unit 22 includes incident log data or records regarding a plurality of incidents occurring prior to the repairs for the one or more locomotives. FIG. 3 shows an exemplary portion 40 of the incident log data contained in incident log data storage unit 22. The incident log data may include a customer identification number 42, a locomotive identification number or unit 44, the date 45 when the incident occurred, an incident code 46, an incident code description 48, etc.

[0026] As suggested above, additional data used in the present invention include operational parameter data indicative of a plurality of operational parameters or operational conditions of the machine. The operational parameter data may be obtained from various sensor readings or observations, e.g., temperature sensor readings, pressure sensor readings, electrical sensor readings, engine power readings, etc. Examples of operational conditions of the machine may include whether the locomotive is operating in a motoring or in a dynamic braking mode of operation, whether any given subsystem in the locomotive is undergoing a self-test, whether the locomotive is stationary, whether the engine is operating under maximum load conditions, etc. It will be appreciated by those skilled in the art that the repair data storage unit, the incident log data storage unit, and the operational parameter data storage unit may respectively contain repair data, incident log data and operational parameter data for a plurality of different locomotives, individually locomotive models that may be distinctly configured relative to one another, such as may occur when a new model introduces new sub-systems or sub-system upgrades into the locomotive. It will be further appreciated that the operational parameter data may be made up of snapshot observations, i.e., substantially instantaneous readings or discrete samples of the respective values of the operational parameters from the locomotive. Preferably, the snapshot observations are temporally aligned relative to the time when respective incidents are generated or logged in the locomotive. For example, the temporal alignment allows for determining the respective values of the operational parameters from the locomotive prior, during or after the logging of respective incidents in the locomotive. The operational parameter data need not be limited to snapshot observations since substantially continuous observations over a predetermined period of time before or after an incident is logged can be similarly obtained. This feature may be particularly desirable if the system is configured for detection of trends that may be indicative of incipient failures in the locomotive.

[0027] FIG. 4 shows an algorithm of the triage or sorting process of the present invention. Subsequent to start step 102, step 104 allows for receiving incident log data comprising one or more incidents from a plurality of machines. Step 106 allows for assigning a predetermined incident severity rating to the respective incidents. By way of example and not of limitation, the incident rating may be classified as red (R), yellow (Y) or green (G). It will be appreciated, however, that one may choose to use more or less than three classifications of the incident severity rating. Table 1 below shows definitions of the above incident log rating classifications.

[0028] Prior to return step 110, step 108 allows for selectively setting an incident weighing value to each respective incident based on the assigned incident severity rating. For example, if the incident is classified as a green incident, then the incident weighing value of that incident may be lower compared to the incident weighing value of incidents classified as red incidents. Similarly, an incident which is classified as a yellow incident may be assigned an incident weighing value which is intermediate between the red and the green incident weighing values.

[0029] FIG. 5 shows another algorithm in accordance with another embodiment of the present invention. Subsequent to start step 152, step 154 allows for receiving incident log data comprising one or more incidents from a plurality of machines. Step 156 allows for receiving operational parameter data from the plurality of machines. Step 158 allows for executing a set of incident-authentication rules or filters indicative of whether a received incident actually corresponds to a faulty condition or not.

[0030] Exemplary incident-authentication rules may be seen in FIG. 6. As shown in block 180, an incident-authentication rule may be a function of one or more data fields, e.g., operational parameters, and, if desired, an incident code or combinations thereof. In block 180, data field 1 represents a particular operational parameter from a data record, and a respective conditional logic operator is applied to the operational parameter being processed. The issue message text is a data field that contains a message describing the condition identified when the incident-authentication rule is triggered, e.g., water temperature sensor may be bad. “P. Smith” represents a data field indicative of the owner or individual assigned to resolve issues associated with a respective subsystem of the machine. It will be appreciated by those skilled in the art that more complex incident-authentication rules are possible. An example of a more complex rule is exemplified in block 182 in FIG. 6. The incident-authentication rule of block 182, in addition to executing logical or mathematical functions on the four identified operational parameters, e.g., data fields 1, 14, 28 and 29, identifies a given incident code, e.g., incident code XXXX, that must occur in order for the incident authentication rule to be triggered. It will be appreciated that the format used in blocks 180 and 182 are merely exemplary since many other formats can be applied to implement the present invention. It will be appreciated that one could define even more complex incident-authentication rules than the ones exemplified in blocks 180 and 182 by using multiple combinations of logical and/or relational operators. It will be further appreciated that the authentication rules can be nested to incorporate temporal information, that is, time-related information relative to the occurrence of temporally distinct incidents. For example, such nested rules may be set to be triggered depending on the magnitude of the level of change in one or more operational parameters relative to recent incidents, such as the two most recent incidents, etc. Similarly, such nested rules could be triggered based on the number of previous incident occurrences over a predetermined period of time, such as whether a given incident has occurred a predetermined number of times over the last month, week, day, etc. It will be apparent that the incident occurrences for triggering such nested rules need not be limited to single incidents since, as suggested above, respective cluster combinations of distinct incidents could be used for triggering the authentication rules. To distinguish one incident-authentication rule from another, each rule may be assigned a respective code identifier of the form TXX, where XX represents a unique alpha numeric combination. Examples of identifiers may be T03 and TF4. As with the incident code format, one may choose any suitable identifier format as long as the chosen identifier format allows for defining a unique identifier for each incident-authentication rule.

[0031] Returning to FIG. 5, step 160 allows for assigning a predetermined incident severity rating to the respective incidents. At step 162, as suggested an incident count value may be incremented if the incident has been authenticated by a respective incident authentication rule. It will be appreciated that there may be conditions in the operational parameters of the machine that can allow for disregarding some incident log data. One example of an incident-disregarding condition may occur when the value of the operational parameter corresponding to locomotive speeds is zero. In this manner, depending on whether the locomotive is moving or not, one can weigh the incident log data accordingly. It will be appreciated that the incident count value need not be incremented only for red or yellow incident categories since any of the categories may be selected to be counted. For example, one could choose to increment the incident count value just for red incidents, while ignoring all of the yellow and green incidents. In the foregoing example, the condition of locomotive speed being greater than zero is a criteria that can be selectively applied to a subset of incident log data or to all downloaded incident log data. Prior to return step 166, step 164 allows for processing the respective incidents based on the respective incident severity rating.

[0032] Below is one illustrative example of the sorting process of the present invention. Given the following data log record:

[0033] Mon, Jan. 18, 1999, 23:45:34, 987698563, 10-1305, “Water Temperature>230 Degrees”, 22.45, 8, 23.6, . . . ;

[0034] Given the incident severity ratings listed on Table 2 below and further given the following incident rules:

[0035] Rule T01: if {(incident code=“10-1305”) and (speed>0) and (water pressure<25)} then “Coolant Level May Be Low” with owner=“h jones”

[0036] Rule T02: if {(speed>0) and (throttle notch=8) and (water pressure>=25)} then “Water Temperature Sensor May Be Bad” with owner=“j doe”

[0037] Based of the foregoing assumptions, then the process of the present invention would allow for parsing the data log record into its various data fields. For example, in the exemplary data log record listed above, the occurrence time of the incident is Monday, Jan. 18, 1999, 23:45:34, which can be formatted to be displayed in seconds so as to result in a trigger time of 987698563, the exemplary incident code is 10-1305, the incident description is “water temperature larger than 230 degrees”, operational parameter one (e.g., locomotive speed) equals 22.45 MPH, operational parameter two (e.g., throttle notch ) equals 8 units. Operational parameter three (e.g., water pressure) equals 23.6 pressure units. As suggested above, the process of the present invention would allow for looking up or assigning the incident severity rating and for determining the owner and any other additional criteria associated with the incident. In this example, because the incident code severity rating of incident code 10-1305 is yellow and the value of the locomotive speed was greater than zero when the incident occurred, then the incident count value for incident code 10-1305 is incremented by one. The process would then allow for executing the incident-authentication rules against the record fields. Since the incident codes is 10-1305 and the locomotive speed value is greater than zero and the water pressure is less than 25, rule T01 would be triggered so as to indicate a true condition and as a result the count for rule T01 is incremented by one. In addition because rule T01 was triggered to authenticate incident 10-1305, then, P Smith, the designated individual would be automatically notified via E-mail or any other suitable means of communication, pager signal, telephone, Internet, etc. In addition, since incident code 10-1305 was authenticated by rule T01, such incident could now be inputted into the diagnostic tools for CBR analysis and the like. In the case of rule T02, the locomotive speed value is greater than zero but the water pressure is not greater than or equal to 25, therefore rule T02 would not be triggered and would not authenticate a true incident condition for incident 10-1305 and, in this case, the incident count value for rule T02 would not be incremental. As suggested above, the process of the present invention allows for reporting authenticated occurrences of critical incidents, triggering true incident conditions, and their respective count values. In this case, no report would be made to “j doe” since rule TO2 was not triggered and thus no authentication of a condition indicative of a possible bad water temperature sensor was made. At this point, such condition may be optionally disregarded and not be inputted into the diagnostic tool.

[0038] Exemplary report messages for the above example could be as follows:

[0039] 10-1305 “Water Temperature Exceeded 230 Degrees” (1) p smith; and

[0040] T01—“Coolant Level May Be Low” (1) h jones;

[0041] where a first data field could contain the applicable incident code or rule, e.g., 10-1305, or rule T01; a second field could contain the incident description or incident rule message, e.g., “Water Temperature Exceeded 230 Degrees” or “Coolant Level may be Low”; a third field may contain the incident weighing value, e.g., 1; and the last data field in this example could includes the name of the individual, e.g., “p smith” or “h jones” assigned to be responsible for the subsystem affected by the incident code or responsible for the incident rule associated with that incident code.

[0042] 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.