Case based reasoning

By Murray Wiseman

Optimal Maintenance Decisions (OMDEC) Inc.

http://www.omdec.com/

 

 

It is not enough to improve just incrementally from your past performance or that of other company divisions. To compete globally, you must look everywhere to learn new methods. Make yourself a student of the best of the best, particularly in unrelated business sectors.

–        John D. Campbell[1]

 

 

Introduction

A  thin line separates diagnostics from prognostics. Condition based maintenance (to be discussed in detail in Part 3 page 75) detects potential failures, which, in themselves, provoke relatively minor consequences. When maintenance personnel detect and repair potential failures, they avoid the dire consequences of a functional failure. In a similar vein, diagnostics begin with the investigation of a “fault” indicator, which, in and of itself, often has few or no consequences, but, which portends a more serious functional failure. Hence the diagnostic process often meets the RCM criterion for “on-condition maintenance” as stipulated by Nowlan and Heap (see page 75).  One or more of a variety of fault indicators can initiate the troubleshooting process. Some warn of failure of back-up functions. Others indicate the failing performance of some function in a subsystem. In all cases, we require a quick and efficient process, based on the application of knowledge and experience, that will trace the fault indicator to its root cause (that is, its failure mode), whereupon we will remediate the cause through a repair or replacement action.

 

A case based reasoning system extends the five fundamental reliability-centered knowledge elements introduced in Chapter 1 (page 11). Its database structure classifies knowledge such that day-to-day experience may increment, expand, and refine the knowledge base. Not only does CBR result in quick, efficient, guided[2] information retrieval but the process itself enables collaboration, retention, revision, and reuse of knowledge.

 

Figure 1.  The case based reasoning troubleshooting process.

Intelligent agents assist maintenance troubleshooters through case based reasoning (CBR).

Figure 1 illustrates four of the five CBR functions:

 

1. To identify a range of candidate (possible) solutions given the symptom(s),
2. To gather additional information that confirms or refutes the possible solutions,
3. To determine the most likely solutions (symptoms similar to the situation as described),
4. To evaluate the proposed solution, and
5. To update the knowledge base (Figure 3) by learning from this experience.

 

Efficient Troubleshooting

Intelligent troubleshooting poses the right questions in the best order. A well designed case based reasoning system guides the technician or engineer along the most practical and least costly path to a solution. It poses questions and suggests solutions by considering relevant data and by evaluating:

Þ    Similarity of past cases to the current symptoms

Þ    Frequency of occurrence of similar cases

Þ    Cost and time to get an answer

Þ    Cost and time of repairs

Þ    Information gain - the ability of a question to eliminate inappropriate solutions

 

 

Figure 2: A typical CBR CaseBank SpotLight™ session

 

Figure 2 shows a typical CBR session. The  troubleshooting conversational “assistant” does not demand that the technician answer every question. The user may elect to answer or ignore any question, and may provide answers in the most convenient order. The tool suggests but does not enforce a specific question order.  At each step, as the diagnostic effort unfolds, the CBR program re-sequences questions and re-prioritizes solutions by re-evaluating all information known up to that point.

 

Data may be entered manually, or it may be retrieved automatically by querying relevant databases or intelligent test equipment. As the trouble-shooter probes the symptoms, the CBR algorithms “reconsider” the data, pose new questions, and re-evaluate the possible solutions until the user determines that the solution has been found.

 

The CBR tool elicits notes and additional observations during a session where such observations are lacking in the case base. Subject matter experts[3], monitor each completed session, harvesting the data where appropriate for case-base development. Figure 3 illustrates this continuing process.

 

Figure 3: Managing the knowledge base

Figure 3 describes the most significant feature of a case based reasoning system, that of continuous enhancement of the knowledge base. Knowledge integrity is assured through expert review and classification of all completed sessions.

 

Case Base Development

The development of a case based reasoning system requires the use of software. In this chapter we review the product SpotLight[4]. Before embarking on any new development system, we must first assimilate a specialized set of terminology:

 

Terminology

Subject: An item of interest.

Domain / subject breakdown: A tree structure of parents and children that describe the knowledge area to be captured. A subject may have multiple parents.

Attribute: A characteristic that is measurable, testable, or observable. It is attached to one or more parent subjects in the domain.

Attribute structure: Name, Description, Question, Values, References.

Attribute types: Logical (T/F, Y/N), Symbolic list (Corroded, cracked, loose), Ordered list (none, low, med, hi), Integer, Real, Multi-valued (several selections may be valid at once, e.g.: one or more fault codes shown on a display unit).

Attribute categories: Symptomatic (e.g. vibration level), Root causes (e.g. Piston – Status – seized, free, sticking), Configuration (e.g. Power rating HP – 130, 150)

Observation: Assignment of a value to an attribute to describe the current scenario (e.g. Master Caution Light – illuminated).

Case (aka Solution): Concise information representing a type of problem.  Most often representing a failure, but could be an operating error or a normal condition that is often misinterpreted as a problem. 

Casebase (aka Knowledgebase): A repository of cases upon which the reasoning engine operates.

Session: The data created in the process of matching the characteristics of the current problem to the cases in the casebase. A session is an “instance” of a case.

 

Building a knowledge domain

The domain and its cases are built in the SpotLight “Domain/Case Editor”. The domain evolves as cases are developed. Figure 4 is an extract from a domain subject breakdown:

 

Subjects (displayed in the domain in upper case characters) can be physical components or they can be categories used to index physical components (e.g. COMPLAINTS CONCERNING SNOWBLOWER OPERATION).   Attributes (displayed in lower case and prefixed by a “?”) are observable properties or behaviours. They are separable into sub-categories (e.g. Engine sounds .. “With auger clutch engaged”, or “With traction clutch engaged”). The attribute “Lawnmower equipment malfunction” may have the values “Poor cut - uneven”, “Hard to push”, “Vibrates excessively”, “Starter rope hard to pull”, “Normal”. Attribute details (name, description, question, reference, observation cost, observation time, comments, similarities, values, attribute links) are added to the domain and edited using the Domain/Case editor.       Figure 4 Domain knowledge breakdown and expansion of the multi-valued attribute “? LANDING GEAR control panel advisory lights”

 

Building a case

We build a case by populating it with the following information:

1. Title: In the form [Problem Description] due to [Root Cause][5].
2. “Lawnmower performance is unsatisfactory due to a restricted (clogged) air filter”
3. Source: The source of the case, either field experience or a document such as a manual
4. Description: A detailed description of the problem.

“Lawnmower runs erratically and the performance is unsatisfactory, starts with difficulty, surges, loss of power, overheating, runs poorly at top no-load speed”

5. Observations: A structured description of the case’s attributes and their values.
6. Cause[6]: A case can have only one root cause[7].
7. Explanation[8]: The explanation may include: 1) how the fault caused the symptoms, 2) the physical working of the affected component to explain the failure, 3) the chain of events that led to the identification of the root cause.
8. Repair: The Repair details generally include what was done to correct the problem, as well as any repair references. E.g.  parts and supplies needed, the sequence of procedures - preparation, execution, testing special tools needed, safety information effort required (for example, person hours), cost (direct labour, overhead, parts, etc).
9. Reference: References for a case may include: diagrams, video/audio clips, and documents that illustrate observations, repair instructions, or explain the case.
10. Lessons: Lessons for the case may include: tips for avoiding mistakes during troubleshooting as demonstrated by the case, tips for avoiding mistakes during repair, emphasis on key observations or procedures that are new and not common knowledge, comments regarding any general principles learned from the case.
11. Edit history: The Edit History shows who made changes to the case, the status of the case, the date the case was changed, and the comments for the change.

 

Case Study

Over a period of two months during 2004 the fault “NOSE STEERING illuminated” was detected in a fleet of aircraft. Around the world several people were grappling with a similar nose wheel steering problem. The knowledge building process amalgamated the notes from similar sessions. The notes are presented in Figure 5.

 

Previous Notes: Solution cases: #4137-Nosewheel Steering sluggish due to partial blockage of the Steering Manifold Inlet Filter. 2004-12-23 14:15:16 GMT by Vincent, Dominic (Closed) Nose wheel Steering sluggish. Hydraulic supply line checked for debris as fault had only become evident after a #2 edp failure a week or so earlier. Debris was found in the filter gauze in the elbow. Once cleaned steering function checked ''satis''. We are looking back to see if any of our other A/C that have had edp failures have suffered from steering problems as steering hydraulic supply pipes not checked after a failure. 2004-12-15 19:58:34 GMT by Gray, Stuart (Closed) In Service Engineering informs me that as well as the inlet and return filters in the PTU selector valve in system #1 (Service Bulletin 84-29-13) and the alternate landing gear extend system filter unions at the bypass valve and at the reservoir intake, (which we have all come across), there are a few others that merit attention. They are: Rudder PCUs have inlet filter unions; Elevator PCUs have inlet filter unions; Flap Power Unit has an inlet filter union; If you have an ongoing fault that appears after a system has been contaminated, (i.e after an EDP failure) a look at these filters might be worth your while. 2004-12-13 16:23:42 GMT by Gosling, Tom (Referred) The manifold has two filters at the inlet port. The first one is located within the swivel joint P/N SJ504-917-2. The second is an inlet filter P/N FSHX0511200B located within the manifold downstream of the inlet port. This information is being added to the Goodrich CMM. This is not an AMM level component as it is part of the steering manifold. 2004-12-13 16:20:07 GMT by Gosling, Tom (Open)

 

Figure 5 Troubleshooting session notes

During a search[9] and analysis of session notes, it was quickly realized that all those aircraft had experienced a hydraulic pump failure previously. This focused the investigation.  It turned out there was a tiny filter inside an elbow (Figure 6) on the NWS unit that nobody knew about - certainly not in the manuals, that was partially blocked.  Within a week, the knowledge analyst added the new case to the case base, whereupon it became available to the world.

Figure 6 Inlet Elbow filter blockage as a result of a prior hydraulic pump failure

 

The knowledge base was updated to include a new set of observations - a structured description of attributes and their values. The attributes and their values are presented in Figure 7.

 

 

Figure Figure 7 Observations for a new case added to the knowledge base

 

Explanation The recent failure of the engine driven hydraulic pump had contaminated the system. Some of the contamination had collected in the steering manifold inlet elbow filter and had remained there after the flushing. The partial blockage of the inlet filter caused a flow restriction to the hydraulic manifold, which resulted in the sluggish performance when maneuvering. The reduction however, was not enough to trigger the P-SW (pressure switch) fault in the steering control unit. Repair The steering manifold hydraulic supply filter was cleaned. References - AIPC 32-51-16-01 - NLG Steering Manifold Lessons The manifold has two filters at the inlet port. The first one is located within the swivel joint P/N SJ504-917-2. The second is an inlet filter P/N FSHX0511200B located within the manifold downstream of the inlet port. This information is being added to the Goodrich CMM. This is not an AMM level component as it is part of the steering manifold.

 

The seed case base

Before implementing CBR in a maintenance organization, we must first build a seed case base of a sufficient[10] number of cases. Figure 8 illustrates the development of the seed case base from 1) existing work order and troubleshooting records, 2) failure modes and effects analysis records, and 3) OEM maintenance and troubleshooting  (fault isolation) manuals.

 

 

Figure 8: The seed case base

 

Casebase Growth

Having deployed the CBR system with a Seed Casebase, the system itself becomes a powerful knowledge capture mechanism, and the casebase grows as new cases are discovered during its use.  The chart in Figure 9 illustrates the expected pattern as the case base matures.  The left side of the graph shows low initial usage as the seed case base is deployed in stages, gradually bringing on more and more users until it is part of normal operations.   

 

Performance measurement

Figure 9: CBR performance results

CBR measures its own performance by tracking the usage, the hit rate and the monthly average number of solved sessions.  Figure 9 depicts the growing usage and accuracy of CBR in diagnosing a jet propulsion engine product line over two years.

 

Conclusions

The scale and unabated growth of mechanization and automation in all walks of human endeavor gave rise to the diagnostic approach known as case-based reasoning. CBR extends the structure of the knowledge gained through the application of reliability-centered maintenance. Along with advanced condition monitoring tasks, CBR assists the modern maintainer to satisfy increasingly pressing economic, environmental and safety demands for:

• Better first-time fix of both potential and functional failures
• Cost reduction / Cost avoidance
• Less troubleshooting time
• Rapid planning for unscheduled maintenance events
• Reduced (unnecessary) parts replacements
• Reduced unscheduled service interruptions
• Increased asset availability
• Preservation and use of intellectual assets
• Capture of “walking knowledge” prior to retirement or attrition
• Maximized utility of new staff
• Focused efforts of expert staff on toughest problems

 

Case based diagnostic reasoning, encompassing a detection, processing, and decision process is truly a form of condition based maintenance or CBM, whose principles we describe in great detail in the chapters of Part 3, page 75.

 

This article was extracted from “Reliability-centered Knowledge” by Murray Wiseman, VP OMDEC. OMDEC is the commercial developer of the EXAKT CBM optimizing system, which is demonstrated in streaming video at www.omdec.com/misc/ABBdemo.wmv.