1

Trends in the Development of System-Level Fault Dependency Matrices

Satnam Singh

Senior Researcher - Diagnosis & Prognosis Group, India Science Lab, General Motors Global R&D GM Technical Centre India Pvt Ltd, Creator Building, International Tech Park Ltd.

Whitefield Road, Bangalore - 560066, INDIA 91-080-41733016, satnam.singh@gm.com

Steven W. Holland

Research Fellow- Diagnosis and Prognosis Group, Electrical & Controls Integration Lab, General Motors Global R&D GM Technical Center, 30500 Mound Road, Warren, MI, 48090 USA

01-586-986-1085, steven.w.holland@gm.com

Pulak Bandyopadhyay Lab Group Manager- Diagnosis & Prognosis Group, India Science Lab, General Motors Global R&D

GM Technical Centre India Pvt Ltd, Creator Building, International Tech Park Ltd. Whitefield Road, Bangalore - 560066, INDIA

91- 80-4041-4991, pulak.bandyopadhyay@gm.com

Abstract—A Dependency matrix (D-matrix) is a consistent and systematic way to capture hierarchical system-level fault diagnostic information. The D-matrix is derived from a dependency modeling framework to capture the causal relationships between failure modes and symptoms. D-matrices are developed from various sources such as historical field failure data, service documents, engineering schematics, and Failure Modes, Effects and Criticality Analysis (FMECA) data. Here, we survey the existing research work on developing D-matrices from disparate data sources and data formats. We classify the D-matrices based on their data source and the imperfectness of symptoms for both boolean and real-valued [0,1] D-matrices. An industrial perspective is offered to describe the pros and cons of various types of D-matrices along with the challenges faced while developing and applying them for vehicle health management. 1 2

TABLE OF CONTENTS

1. INTRODUCTION ............................................................ 1 2. CATEGORIZING D-MATRICES BASED ON SOURCES .... 3 3. CATEGORIZING D-MATRICES BASED ON

IMPERFECTNESS OF SYMPTOMS .......................................... 6 4. COMPARING D-MATRICES .......................................... 6 5. INTEGRATING D-MATRICES ........................................ 7 6. INTEGRATING D-MATRIX WITH DIAGNOSTIC

REASONER ............................................................................ 8 7. CONCLUSIONS ............................................................. 8 REFERENCES ........................................................................ 9 BIOGRAPHY .......................................................................... 9

1978-1-4244-3888-4/10/$25.00 ©2010 IEEE. 2 IEEEAC paper #1565, Version 2, Updated December 30, 2009

1. INTRODUCTION

Technological advances in electronics, wireless communications, and telematics are providing capabilities to collect real-time data from many parts of an automobile. The collected data provides an excellent opportunity to monitor the entire vehicle’s health and perform fault diagnosis and prognosis on the vehicle. Modern vehicles typically consist of as many as fifty or more electronic control units (ECUs) with many of them containing in excess of a million lines of source code. In such complex systems, multiple modules can sometimes interact in unforeseen and complicated ways which may lead to interacting or dependent faults. Detecting and isolating such interacting faults is a challenging problem. In this paper, we discuss a systematic framework which provides a way to capture causal relationships between failure modes (or root cause failures) and symptoms (a set of fault codes, diagnostic trouble codes, automated tests, technician tests, observed symptoms, etc.) relating to a given system. This kind of systematic diagnostic framework is known as a Dependency matrix or D-matrix. The relationships among failure modes and symptoms should be interpreted as causal i.e., failure modes “cause” symptoms. Also there could be causal relationships among multiple failure modes and multiple symptoms i.e., many failure modes may be causing a single symptom and vice versa. In such situations finding the root cause becomes a complex problem. However, using the D-matrix, one can develop intelligent diagnostic reasoners to solve the root cause problem.

The D-matrix is widely used in the complex systems such as aircraft, spacecraft, nuclear power plant, etc. There are commercial tools, e.g., TEAMS® [1], etc. which employ D-matrix based models for system-level diagnosis. The IEEE also published the "diagnostic inference model" as a standard based on the D-matrix in IEEE Std 1232-2002 [2].

2

Figure 1: Off-board and On-board D-matrix

Figure 2: Sources of Developing the D-matrix

Sheppard et al. has provided a theoretical analysis of the D-matrix and proved that a boolean D-matrix with single fault assumption is linearly separable [3].

There are several benefits of using a D-matrix-based framework for on-board and off-board fault diagnosis. As shown in Figure 1, D-matrix (D-matrix) is a framework to capture causal dependencies (dij) among failure modes (fi) and symptoms (sj). The dependencies could be represented as a boolean i.e., 1 (related) or 0 (not related) or a real-number in [0,1] which indicates the probability of detecting a specific failure mode. The off-board implementation employs a complete (full-order) D-matrix and relies on data collection either remotely via telematics or directly by a technician in the service bay and is then transferred to a remote center for the processing. The remote decision support center processes the vehicle health data and fault codes via an advanced reasoner for the root cause analysis.

The off-board D-matrix involves data rich decision making and planning. Due to the memory constraints, the on-board D-matrix is a reduced-order and compressed version. It is installed either on a diagnostic electronic control unit (DECU) or existing ECU which collects the vehicle information such as fault codes and sensor values and processes the same through a reasoner to detect faults and estimate severity of faults. If the fault’s severity is high, the customer may need to be notified of need for quick repair at a nearby dealer via a telematics service. Figure 1 illustrates the off-board and on-board benefits of the D-matrix along with the need to integrate the D-matrix development into the vehicle development process.

Another benefit of the D-matrix-based framework is that the D-matrix could be utilized to assess a given system from a testability and diagnosability point of view [4] during the design stage i.e., built-in diagnostics. If a component has

3

good testability and diagnosability metrics, then we can efficiently isolate existing faults associated with it. One can also compute which failure modes are ambiguous and which failure modes are detectable and thus, can be isolated. In addition, we can explicitly calculate the number of redundant tests and the dollar cost to perform isolation using a commercial tool such as TEAMS®. Another important benefit is that the D-matrix provides a standardized means to describe and verify requirements to/from the component supplier.

There are several ways to develop a D-matrix such as manual or automated text processing of service procedures, modeling using engineering documents and domain knowledge and data mining of field failure data (case-based approach). Figure 2 shows various data sources for preparing the D-matrix. One of the approaches is to start with signal flow diagrams (or structural diagrams) and engineering knowledge of the system such as FMECA data, signal data, ECU data etc. [6]. We termed this approach as the Engineering D-matrix (EDx). This can be extremely engineering intensive and preparing such a vehicle model from scratch might require a significant amount of engineering time and money. Another approach is to apply data mining techniques for extracting a D-matrix from field failure or warranty databases [7] which we termed as the Historical data D-matrix (HDx) approach. The key advantage of this approach is significant savings in D-matrix preparation time. However, the HDx may have much lower fidelity than obtained with the EDx due in part to noise embedded in the field failure data as well as the lack of explicit engineering design information. Developing the HDx also requires a significant amount of audit from subject matter experts (SMEs). A third approach is to capture the D-matrix from documented service procedures with the assumption that the existing service procedures are, in fact, correct [8]. We term this approach as the Documents D-matrix (DDx) which may also require text mining and information retrieval technologies to capture the D-matrix from the source documents (hopefully represented in a machine readable format).

Due to different types of data being utilized in the development of above mentioned D-matrices (i.e., EDx, HDx, and DDx), it can become very challenging indeed to compare and integrate them. The failure modes and symptoms may contain different terminology and even different granularity in each of these matrices e.g., EDx failure modes are defined typically at the signal and FMECA-level where DDx and HDx capture failure modes mostly defined at the level of circuit-level failures and serviceable part, respectively. Thus, to achieve the highest fidelity D-matrix, it is essential to integrate the different matrices. There are several benefits of comparing them as well e.g., comparisons could be done between the HDx of different vehicle platforms to understand the differences in system, subsystem and component-level diagnostics. If HDx and DDx are compared, the differences among them could point to potentially inappropriate repairs in the field

and it can also help to improve the corresponding service procedures.

In this paper, we make following contributions: • We provide a detailed review of various ways to

prepare D-matrices for real world systems. An industrial perspective is offered to describe the pros and cons of various types of D-matrices - i.e., EDx, HDx, and DDx.

• In order to achieve a high fidelity model and implement system-wide diagnostics it is necessary to integrate and compare the above D-matrices. We show that integrating and merging has several benefits.

• Since each of the D-matrices (EDx, HDx, and DDx) has its own domain-specific syntax and granularity to describe failure modes and symptoms, it is necessary to employ some kind of semantic matching. We briefly discuss the semantic problems while integrating and comparing various D-matrices.

2. CATEGORIZING D-MATRICES BASED ON

SOURCES

In this section, we present a literature survey of different sources from which we can develop the D-matrices.

Engineering D-matrix (EDx)

Using the engineering data such as the FMECA, signal definitions, IO specifications, we model how a fault (or cause) propagates to the various monitoring points (and appears as a symptom). One of the EDx types is multi-signal dependency model which requires first-order cause-effect dependencies to be modeled and higher-order dependencies to be inferred via reachability analysis. This multi-signal model corresponds closely to the engineering schematics of the system. Multi-signal models represent the system in a failure-space and hierarchical manner. The multi-signal directed graph consists of nodes (modules, test points, logical nodes) and directed links. The propagation paths of the effects of a failure are captured in terms of a directed graph where signals represent the manifestations of

Table I Engineering D-matrix (EDx) of a Cassette Player System

Tweeter Woofer Mid. Light s1 s4 s2 s5 s3

Power (G) 1 1 1 1 1 1 LED (G) 0 0 0 0 0 1 Tape Head (G) 1 1 1 1 1 0 Tape Head (F) 1 1 0 0 0 0 Pre-amp (G) 1 1 1 1 1 0 Power-amp (G) 1 1 1 1 1 0 Power-amp (F) 0 1 0 1 0 0 Woofer (G) 0 0 1 1 0 0 Woofer (F) 0 0 1 0 0 0 Midrange (G) 0 0 0 0 1 0 Midrange (F) 0 0 0 0 1 0 Tweeter (G) 1 1 0 0 0 0 Tweeter (F) 1 0 0 0 0 0

4

Figure 3: A Simple Engineering Model of a Cassette Player System [3]

Figure 4: Soft and Hard Historical Fault D-matrices of Example 1

a failure. More details are provided in [6]. Here, we would like to show a simple example of multi-signal model which has been taken from [6]. Figure 3 shows a simple engineering model of a cassette player. The signals s1, s2, s3, s4, and s5 correspond to Treble, Bass, Midrange, signal to noise ratio (at 1 Watt nominal output) and harmonic distortion (at rated power), respectively. Each component (power supply, tape head, etc.) is associated with a list of signals that it affects. Also, it further includes "G" for general failures and "F" for functional failures in a specific component. The signals s1, s2, and s3 are monitored at the respective speakers. Table I shows the EDx of the cassette player model as shown in Figure 3. The entries of the D-

matrix capture the causal dependencies i.e. 0-unrelated or 1-related between the failure modes and symptoms of the cassette player system.

Historical data D-matrix (HDx)

Another way to prepare the D-matrix is to employ historical field failure data. In [7, 8] Felke et al. developed a method to associate historical data from log files and deferral procedures with fault codes. The authors presented a historical data fault model (D-matrix) for an aircraft that can be used to support an automated diagnostic and maintenance system. The D-matrix was constructed in two steps:

Power Supply

G

LEDG

TapeHead

s1, s4, G

Pre-amp

G

Power amp

s4, s5, G

Woofer

s2, G

Midrange

s3, G

Tweeter

s1, G

Light

s2, s5

s3

s4, s1

Repair Part Part SymptomsEvent Cost Replaced s1 s2 s3RE1 C1 P1 p a aRE2 C2 P1 p a aRE3 C3 P1 a p aRE4 C4 P2 a a pRE5 C5 P2 a p a

Avg. Part Cost Failure Mode Failure Rate s1 s2 s3

(C1+ C2+C3)/3 P1: f1 3/5 2/3 0 0

(C1+ C2+C3)/3 P1: f2 3/5 0 1/3 0

(C4+C5)/2 P2: f3 2/5 0 0 1/2

(C4+C5)/2 P2: f4 2/5 0 1/2 0

Soft-Historical data D-matrix (Soft-HDx)

Avg. Part Cost Failure Mode Failure Rate s1 s2 s3

(C1+ C2+C3)/3 P1: f1 3/5 1 0 0

(C1+ C2+C3)/3 P1: f2 3/5 0 1 0

(C4+C5)/2 P2: f3 2/5 0 0 1

(C4+C5)/2 P2: f4 2/5 0 1 0

Hard- Historical data D-matrix (Hard-HDx)

Example 1: Historical Case-Based Data

5

Figure 5: A Simplified and Partial HDx of an Automobile Fuel System

1) deriving the relationships among multiple observations and multiple repairs 2) assigning a unique fault code to each standard repair with an associated observation. To illustrate the idea of how to develop a Historical data D-matrix (HDx), let us consider an example as shown in Figure 4. The historical case-based data in example 1 shows that there are five repair events (RE1-RE5); out of these five events, two parts P1 and P2 were replaced three and two times respectively. Using these replacement counts of parts P1 and P2, failure rate and avg. part cost are computed which is shown in Soft-HDx and Hard-HDx (Figure 4). If a symptom is present or absent in the Example 1 then it is indicated as p or a respectively. The failure modes are constructed by a combination of parts and symptoms. For example, the historical case-based data shows the symptoms associated with the part P1 i.e., s1 and s2 are symptoms which are correlated with the failure modes P1: f1 and P1: f2, respectively. Since symptom s1 is present thrice out of five times P1 is replaced in the field, we use these co-occurrence counts among symptoms and parts to derive a soft D-matrix, for example: P1: f1 - s1 association weight 2/3 is derived by dividing number of co-occurrence counts for P1: f1 - s1 i.e., 2 by total number of co-occurrence counts of s1 or s2 with P1, i.e., 3. We can also consider purely binary (hard, meaning not fuzzy) D-matrix (Hard-HDx) which show that if there is a 1 in the D-matrix, it implies that a specific failure mode can be detected by a specific symptom s (i.e., f1 can be detected by s1).

To illustrate a real-world example of the HDx, we show a simplified and partial HDx of an automobile fuel system in Figure 5. The HDx captures the failure modes upto the

serviceable part-level e.g. fuel level sensor, fuel pressure sensor, etc. The symptoms could be fault codes, diagnostic trouble codes (DTCs) or any other automated tests which are recorded in the field data. The HDx primarily captures the causal dependencies among the replaceable parts and the automated fault codes. For example, a fault in the fuel level sensor could be completed detected via a fuel level sensor circuit-low voltage DTC (Figure 5).

Documents D-matrix (DDx)

Kramer et al. has developed a translator to convert unstructured and structured knowledge (Figure 6) into a form that the decision support system can process [6]. They termed this kind of knowledge base for decision support as a fault model. The entire translation process is automated,

Figure 6: A Simplified View of Document D-matrix (DDx) Creation [8]

Fuel Tank Press. (FTP) Sensor

(F1)

Fuel Level Sensor (F2)

FTP Sensor Performance (S1)

Failure modes Symptoms

0.9 1 0 0

0 0 0 1

0 0 0.8 0

.

.

. ...

S1 S2 S3 S4F1

F2

F3

FTP Sensor Circuit Low Voltage (S2)

Lean Fuel Trim System (S3)

Fuel Level Sensor Circuit Low Voltage (S4)

Repair costs,failurerates

. . .

.

.

.

Fuel Pressure Sensor (F3)

Historical data D-Matrix (HDx)

Documents

Filter

Domain-specific

filter rules

Fault Model (DDx)

Knowledge Extraction

Text extraction

rules

6

Figure 7: A Simplified and Partial DDx of an Automobile Fuel Tank Pressure Sensor

trainable, and extensible; however, it is dependent on the rules defined by user, which requires domain-specific knowledge for data processing. The DDx captures more detailed failure modes as compared to HDx. As shown in Figure 7, an automobile fuel tank pressure (FTP) sensor could have several circuit-level failures e.g. open/high resistance/short to ground/short to voltage failures in the 5-volt reference circuit of the FTP sensor circuit. Apart from automated fault codes or DTCs, these circuit-level failures need to be detected via technician tests and scan tool measurements at the repair shop. For example, a technician can perform a manual circuit test (test the FTP sensor 5 volt reference for a short to voltage) and/or scan tool measurement (FTP sensor voltage between 4.2 to 5V) to detect the short to voltage failure in the 5-volt reference circuit of the FTP sensor.

3. CATEGORIZING D-MATRICES BASED ON

IMPERFECTNESS OF SYMPTOMS

We can also categorize D-matrices based on the values of D-matrix entries; i.e., the element of the D-matrix could be binary or real numbers. Here, we briefly summarize this categorization, a detailed discussion is provided in [10].

Hard (boolean) D-matrix

The binary D-matrix considers only binary relationships among failure modes and tests. It considers the correlations among failure modes and tests as only boolean i.e., 1 (related) or 0 (not related). In this case, we also assume that tests are perfect i.e., there are no missed detection and false alarms. One of the major benefits of the hard D-matrix is that it declares a component either good or bad using diagnostic outcomes and there is a small ambiguity group of possible failures i.e. it is less likely that the failures would have same symptom signatures.

Soft D-matrix

In this D-matrix, we represent the dependencies among failure modes and tests as soft or fuzzy values. An appropriate way to implement this is by considering tests as asymmetric (i.e., if a test fails then there is a fault, but if it passes, we are not sure if there is a fault or not), and we can also add uncertainty to test. We also consider that each “failure mode-test” pair has a detection probability (Pdij) and a probability of false alarm (Pfij) which captures the uncertainty associated with detection [10]. The soft D-matrix works well if one has good estimate of detection probabilities Pdij for all the failure modes of the system. One of the drawbacks of this type of D-matrix is that the testability analysis gives a large ambiguity group with a probability distribution which doesn't help to pinpoint a failure at the repair shop.

4. COMPARING D-MATRICES

Figure 8: Engineering D-matrix (EDx) of Example 2

7

Figure 9: Documents D-matrix (DDx) of Example 2

Figure 10: Hard-Historical Data D-matrix (HDx) of Example 2

Here, we compare the various D-matrices (EDx, DDx, and HDx) via a simple example [1]. The EDx model captures the observability among failure sources and symptoms. For the Example 2 as shown in Figure 8, if there is a failure f1, then it can propagate through entire chain of f2, f3, and f4. Hence, the symptoms s1 and all the downstream symptoms, i.e., s2, s3 and s4 can detect the failure mode f1. Similarly, failure mode f3 could be detected by s3 and downstream symptom s4 as well. EDx captures these kinds of causal dependencies via reachability analysis [6].

The DDx of Example 2 is constructed via the service tree which is shown in the Figure 9. The service tree is constructed by service experts using the engineering knowledge and a priori knowledge about the failures. For example, if a technician performs a test s3 (e.g. a voltage test) which is passed or failed then the service tree recommends either the failure mode f4 or guides the technician to perform another test i.e. s2. The DDx shows that f4 could be detected by s3. Similarly, other elements of the DDx can be obtained. The shaded portion of the DDx is obtained via the tracing the symptoms related to a specific failure mode in the service tree, this is also known as reachability analysis. Using the similar process as described for the Example 1, the Hard-HDx is developed for the Example 2 as shown in Figure 8. If a symptom is present or absent in the Example 2 then it is indicated as p or a respectively.

As shown in Figures 9 and 10, the HDx and DDx capture only the partial D-matrix as compared to EDx which captures the entire diagnostic knowledge of the system. This is due to fact that EDx captures causal dependencies between failure modes and symptoms with the SME

(subject matter expert) knowledge; however developing EDx requires significant amount of time and resources. To the contrary, a good amount of HDx and DDx could be developed semi-automatically from the historical data and service documents respectively.

5. INTEGRATING D-MATRICES

Next, we show that integrating D-matrices could involve first matching the failure modes and symptoms and then updating the D-matrix parameters using Laplace or Bayesian smoothing methods [11]. Due to diverse nature of the sources from where these D-matrices are developed there may be significant differences in the names of failure modes and symptoms. For example, the failure modes in the HDx and DDx of the fuel level sensor (Figures 5 and 7) have different level. Hence, before we attempt to solve the D-matrix merging problem, we need to match the names of failure modes and symptoms of the D-matrices. We solve this semantics problem by first performing text similarity by measuring the similarity between the failure modes (and/or symptoms) of the HDx, DDx, and EDx then incorporating domain knowledge/expertise to do the final merging and comparison. After merging failure modes and symptoms from several D-matrices, we need to employ statistical techniques such as Bayesian smoothing to update the parameters of the common D-matrix. Figures 11 and 12 shows that the dependencies of the common D-matrix i.e., eii (Figure 12) are obtained via Bayesian smoothing of dii and hii. The shaded parts in the Figure 11 show the common D-matrix between the DDx and HDx. Integrating the uncommon D-matrix as shown in Figure 12, is a more complex problem. This is due to the need for domain knowledge while merging the entries of the two matrices.

8

Figure 11: Comparing DDx and HDx of Example 2

Figure 12: Integrating DDx and HDx of Example 2

Figure 13: Diagnostic Reasoners

While merging, one has to get two parts of the D-matrix: common and uncommon as shown in Figure 12 and employ domain knowledge for merging the common and uncommon parts. For the uncommon part the domain knowledge is used for merging because some of the elements might be spurious in the D-matrix e.g., if an expert considers that f4-delta entry h42 is spurious then one needs to drop h42 while merging the D-matrices.

6. INTEGRATING D-MATRIX WITH

DIAGNOSTIC REASONER

In order to utilize the diagnostic information stored in the D-matrix, one needs algorithms and methods to infer the root cause. These algorithms are known as diagnostic reasoners as shown in Figure 13. Most of the diagnostic reasoners take the discrete outcomes of the symptoms and D-matrix as an input and give a ranked list of failure modes according to their likelihoods. If the symptoms are derived from continuous-valued sensory data then statistical techniques such as trending, range checking etc. are employed to derive the discrete (e.g. binary- pass/fail) test outcomes. The rule-based diagnostic reasoners are easiest to develop, however it

is hard to develop probabilistic rules and continuously update them. The set-partitioning based diagnostic reasoners are well matured and applied to large problems [1][6]. The case-based reasoners are another popular choice due to their simplicity however they are primarily based on distance-based metrics which are computationally expensive. There exist several graphical models-based reasoners such as hidden Markov models and Bayesian networks which provides an excellent alternative to other reasoners due to their efficient handling of probabilistic inference computations. The detailed analyses of the D-matrix based diagnostic reasoners in beyond the scope of this paper, we recommend [3] by Sheppard et al. for a good summary of D-matrix based diagnostic reasoners.

7. CONCLUSIONS

The D-matrix-based fault modeling is one of the popular approaches for system-level diagnosis which is widespread in complex systems such as aircraft, spacecraft, etc. Most of the existing literature on D-matrix provides only theoretical assessments of the D-matrix. However, they share little on approaches to develop the D-matrix in the first place. Here,

Rule-basedSet partitioningCase-based reasoningHidden Markov models & Bayesian networksFusion of reasoners, …

Outcomes of Symptoms

• Testabilityanalysis• Guided troubleshooting

(off-board)• On-board

diagnosticdecisions

Diagnostic Reasoners

(Multiple fault codes, range checking, model-based residuals, trend analysis)

D-matrix

Symptoms

Failuremodes

s1 s2 s3 s4

f1 d11 d12 d13 0

f2 d21 d22 d23 d24

f3 0 d32 d33 0

f4 0 0 d43 0

9

we discuss several ways to develop the D-matrix from different data sources and disparate data formats. Based on their data sources, we termed three types of D-matrices: Engineering D-matrix (EDx), Documents D-matrix (DDx), and Historical data D-matrix (HDx). We offer an industrial perspective on developing these matrices along with the discussion on pros and cons of each.

REFERENCES

[1] Qualtech Systems Inc., http://www.teamqsi.com.

[2] IEEE Standard 1232-2002, Standard for Artificial Intelligence Exchange and Service Tie to All Test Environments (AI-ESTATE), Piscataway, NJ, IEEE Standards Association Press, 2002.

[3] J. W. Sheppard and S. G. W. Butcher, "A Formal Analysis of Fault Diagnosis with D-matrices," Journal of Electronic Testing: Theory and Applications, 2007.

[4] IEEE Standard 1522 TM-2004, Standard for Testability and Diagnosability Characteristics and Metrics, Piscataway, NJ, IEEE Standards Association Press, 2004.

[5] Qualtech Systems Inc., http://www.teamqsi.com.

[6] S. Deb, S. K. Pattipati, V. Raghavan, M. Shakeri, and R. Shrestha, "Multi-signal flow graphs: a novel approach for system testability analysis and fault diagnosis," IEEE Aerospace and Electronic Systems Magazine, Volume 10, Issue 5, May 1995.

[7] T. J. Felke and J. F. Stone," Method and Apparatus for Developing Fault Codes for Complex Systems Based on Historical Data," US Patent 003318 A1, Jan 2004.

[8] S.P. Eagleton and T. Felke, "Method and Apparatus using Historical data to Associate Deferral Procedures and D-matrix," US Patent 6,725,137 B2, Apr 2004.

[9] K. M. Kramer, S. C. Gaetjens and H. C. Voges, "Trainable, Extensible, Automated Data-to-Knowledge Translator," US Patent 7096210 B1, 2006.

[10] S. Singh, A. Kodali, K. Choi, K. Pattipati, S. M. Namburu, S. Chigusa, D. V. Prokhorov, and L. Qiao, “Dynamic Multiple Fault Diagnosis Problem Formulations and Solution Techniques,” IEEE Trans. on Systems, Man and Cybernetics: Part A, Jan 2009.

[11] J. Luo, S. Ghoshal, A. Mathur, K. Pattipati, "Adaptive Maintenance Knowledge Bases for Field Service," IEEE Aerospace Conference, Mar 2007.

BIOGRAPHY

Satnam Singh is currently working as a Senior Researcher in the GM India Science Lab. He received his PhD degree in Electrical and Computer Engineering from the University of Connecticut (UConn) in 2007. He received his MS degree in

Electrical Engineering from the University of Wyoming in 2003. His research interests include fault modeling, fault diagnosis and prognosis, graphical models, pattern recognition, data mining and optimization theory.

Steve Holland is a Research Fellow in the Electrical and Controls Integration Lab of GM Global R&D in Warren, Michigan, USA. He is currently Chief Technologist for GM’s global research initiative in diagnosis & prognosis being applied to on-board vehicle applications,

warranty/service applications, and manufacturing. Steve joined GM in 1970 while a student and was first involved in early research on robotics, vision and computer-based manufacturing and later led all GM’s computer research activities in machine perception, artificial intelligence, and advanced computing methods through 1991. From 1991-96, he directed the GM robotics development effort. From 1997-2002, he served as a founding Director of the GM Controls, Robotics & Welding activity that was responsible for support of all GM plants. From 2002-06, he served as Director of the Manufacturing Systems Research Lab and Chief Scientist for Global Manufacturing. He is a Fellow of IEEE and served as an IEEE distinguished lecturer. In 1998, he received the Joseph F. Engelberger Award for his contributions “to the advancement of the science of robotics in the service of mankind.” He is a member of the Board of Directors of the MATHCOUNTS Foundation. Mr. Holland has a Bachelors in electrical engineering from GMI and a Masters in computer science from Stanford.

Pulak Bandyopadhyay is a Technical Fellow and a Lab Group Manager for the Diagnosis and Prognosis Group at the General Motor’s India Science Lab. Pulak received his Ph.D. from the University of Wisconsin–Madison in the area of Production Engineering. He is a senior

member of the Society of Manufacturing Engineers, and served in the board of directors of North American Manufacturing Research Institute. Pulak’s research interest includes math-based modeling of processes and systems, agile/reconfigurable system design, data mining technologies for diagnosis and prognosis, and real-time monitoring and control. Pulak has won several external and internal GM awards including SME Outstanding Young Manufacturing Engineer, R&D100 Top innovation award, and GM’s most prestigious “Boss Kettering” award three times.