By Murray Wiseman (Extracted from Reliability-centered Knowledge, Chapter 4)

Optimal Maintenance Decisions (OMDEC) Inc.

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]

 

 

引言

智能代理利用案例式推理来协助维修人员进行故障检查或诊断。

Figure 1 The case based reasoning troubleshooting process.

一个案例式推理系统会将知识进行分类并日复一日地根据每天的经历增加和改进此系统，最后达到…

Þ    快速，有效，导航式的信息检索，以及

Þ    知识的汇合，保留，修改和再使用。

 

Figure 1 illustrates the 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 solutions most likely (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 case based reasoning system guides the technician along the most likely and least costly path to a solution. It poses questions and suggests solutions by considering all data and by evaluating these factors:

·        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”[2] session

 

Figure 2 shows a typical CBR session. The SpotLight™ troubleshooting conversational “assistant” does not demand that the technician answer every question. Users may elect to answer or ignore any question, and may provide answers in the most convenient order. SpotLight suggests but does not require a specific question order.  At each step, as the diagnostic effort unfolds, the CBR program re-sequences questions and re-priorizes solutions by re-evaluating all information known up to that point. Data may be manually entered, or automatically retrieved by querying relevant databases or intelligent test equipment. As the troubleshooter probes the symptoms, the CBR algorithms “reconsider” the data, pose new questions, and re-evaluate the possible solutions until the user determines that the problem has been solved. The CBR tool elicits notes and additional observations. Using CBR software, subject matter experts^[3], adapt each completed session to the case base for re-use. 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. CBR provides tools and methods for continuous enhancement of the knowledge base. Knowledge integrity is assured through expert review and classification of all completed sessions.

 

Performance measurement

Figure 4: CBR performance results

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

 

Case Base Development

The development of a case based reasoning system requires the use of software. In this chapter we review CaseBank Technologies’ product  “SpotLight”. 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 knowledge tree structure of parents and children. 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).

 

Building a knowledge domain

The domain and its cases are built in the SpotLight “Domain/Case Editor”. The domain evolves as cases are developed. The following 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.

 

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]^[4].

“Lawnmower performance is unsatisfactory due to a restricted (clogged) air filter”

2. Source: The source of the case, either field experience or a document such as a manual
3. 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”

4. Observations: A structured description of the attributes and their values.
5. Cause^[5]: A case can only have one root cause.
6. Explanation^[6]: 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.
7. 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).
8. Reference: References for a case may include: diagrams, video/audio clips, and documents that illustrate observations, repair instructions, or explain the case.
9. 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.
10. 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.

 

The seed case base

Before implementing CBR in a maintenance organization, we must first build a seed case base of a sufficient^[7][8] number of cases. Figure 5 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 5: The seed case base

 

Conclusions

The scale and unabated growth of mechanization and automation in all walks of human endeavor gave rise to case-based reasoning. Along with advanced proactive tasks, CBR assists the modern maintainer to satisfy increasingly pressing economic, environmental and safety demands for:

• Better first-time fix
• Cost reduction / Cost avoidance
• Less troubleshooting time
• Rapid planning for unscheduled maintenance events
• Reduced (unnecessary) parts replacements
• Reduced unscheduled service interruptions
• Improved asset availability
• Effective, quick training of personnel in developing their own keen troubleshooting skills
• 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

 

Do you have any comments or questions on this article? If so send them to murray@omdec.com.