Knowledge Base Approach to Integrated Fmea Essay Example

by finding similarities and differences between various situations.Since the source of improvements are verbal ideas and system behavioral rules, which later evolve into analysis and implementation plans, a specialized Knowledge Base (KB) must be blended into AI systems for expediting and enhancing improvement efforts. This Knowledge Base-AI blend must support the following

CONTINUOUS IMPROVEMENT

All products or processes must be always improved due to improvements in competitors’ products or evolution of customers’ needs.

Besides, a company should be committed to continuous improvement so that its products/processes will remain cost-effective.Before making decisions on how to improve, it is necessary to review previous suggestions and analyze their advantages and drawbacks—to avoid the ones that failed, and to consider the ones that were not implemented.

DECISION MAKING

The best choice (selection of Corrective Action) can be made if exists good knowledge infrastructure, considerable analysis and judgment capabilities, based on integrated criteria such as risk estimation: the higher the risk, the higher is the priority of dealing with the subject.

Thus, KB usage is an ultimate way to construct and quantify the appropriate Risk Priority Number (RPN) for most productive decisions in design, support and maintenance.

EFFICIENCY THROUGH SIMILARITY

Frequently, the knowledge gained while improving one product or process can be applied to improve another. A KB organizes knowledge so that one can quickly access it and port it to other applications. KNOWLEDGE MINE. Ideas, recommendations, experience, success—these are cquired constantly, not just during the weekly quality meetings or brainstorming sessions. A knowledge mine is a mechanism for constantly updating, reviewing, and evaluating experts’ input into the KB.

INTEGRATED FMEA AND THE KNOWLEDGE BASE APPROACH

What is a “Knowledge Base”? Usually, a KB is a combination of so-called “Declarative”

and “Procedural” knowledge. Declarative Knowledge is a set of facts and statistical data about objects, events and situations. Procedural Knowledge is information about courses of action and production rules. These two types of knowledge incorporated into ongoing FM and Effect Analysis (FMEA) make the process Integrated (IFMEA), ready to be automated, and enhance the expertise and capabilities of personnel performing the analysis.

Declarative Knowledge (DK) Aspect of IFMEA DK is a collection of IFMEA libraries, and serves as an organization’s “collective memory”. Every member of the organization contributes experiences, ideas, and knowledge to the DK for the benefit of all members. DK accumulates the information, and as it expands, an organization can converge on quality improvement solutions faster and more efficiently.

The Declarative Knowledge of IFMEA Remark: As an aside, we mention the dynamics of the structure, where all interactions happen continuously, sometimes simultaneously. Field data may arrive during a brainstorming session. The best way to ensure that all IFMEA team members have the latest information, and all previous information, is by using a software package that supports continuous data entry, efficient retrieval, and convenient data presentation. Let us describe some types of DK libraries (databases).

COMPONENT LIBRARY COMPONENT, FAILURE MODES AND CAUSES DATABASES

The first step in IFMEA DK development is to build a Component Database for all the company’s products and processes.

An efficient approach is to identify components for one product/process, and use them as a “template” for other products and processes to which new components are added. During this part of the FMEA DK creation, experts identify components, their possible failure modes, and the associated causes. There are two primary sources of failure modes: Field reports

- A systematic failure reporting procedure feeds the FMEA team with failure modes.These reports arrive in many forms, including customer complaints, service calls, and returned products.

Analysis and experience - R&D and manufacturing personnel are a good source of failure modes. Engineers may review designs and note potential problems. Equipment operators frequently identify product defects as they are being manufactured. Each failure mode is the result of a failure cause.

FMEA team members can determine failure causes in many ways, including brainstorming, interviewing service and manufacturing personnel, or reviewing failure reports.Figure 2 illustrates how IFMEA forms the first stage of DK of a complete relationship between components, failure modes, and failure causes. The shaded sections of the illustration indicate components. The “prepare laminate” component is linked to various failure modes, such as “panel edge is weak”, which in turn is linked to the “blades not set” failure cause. Effective use of the component library provides a rich data base of component behavior, which can be applied to any project containing identical or similar process elements and components.

Formal Suggestions—corrective actions developed during brainstorming sessions, quality meetings, design reviews, or other structured improvement activities. Informal Suggestions—potential corrective actions developed outside the formal process improvement structure. An operator may have an idea regarding improved product quality while driving home from work. Frequently such informal suggestions lead to extraordinary product and process improvement. Remark:As a rule, IFMEA KB should be run on a network, supporting the entry and review of all possible sources for CA and FM&C relationships, storage and retrieval for further evaluation and possible usage.

Corrective Actions, including their advantages & disadvantages. For adopted CAs, the definition includes responsibilities, completion

dates, and tracking of implementation progress.The CA database represents a significant portion of DK, since it contains a wealth of solution information accumulated by the company, the benefits and drawbacks. Corrective Action Database Corrective ActionAdvantagesDisadvantagesResponsibilityRemarksCompletion date per project Visual inspection of installed station increases the probability of detecting defectCreates overcrowding in current factory fabrication ManagerMay require completely new factory layout10/02/97 Place boards in protective package reduces in-transit damage increased cost and volume shipping manager get quotes from shipping co.

The entries in DK6 indicate how well test procedures detect failure modes at any given test level. For example, one way to test for failure on a car’s brake system is to drive and slam on the pedal. This test method is rather dangerous. A better method is to check the brake fluid level or use a road simulator. Detection is characterized by either a rank or by an efficiency range.

IFMEA uses either characterization when evaluating the testing program to detect possible failure causes. Detection [D], Suggested Evaluation Criteria Efficiency Range RankLikelihood Controls Detect the Existence of a DefectFromTo 10Controls cannot detect the existence of a defect. 00. 10 9Controls probability will not detect a defect. 10. 20 8A very poor chance to detect defect existence.

IFMEA supports two methods of Detectability evaluation: experts’ ranking, and test efficiency evaluation. Procedural Knowledge (PK) Aspect of IFMEA The following sections describe the Procedural Knowledge (PK) portion of FMEA.PK1. NEXT-HIGHER-EFFECT CHAIN The chain is called the “NHE Chain” representing the knowledge that every FM is a Next-Higher-Effect (NHE) of a lower indenture level item, but at the same time is an FC for higher indenture level. Chain is critical when trying

to employ the knowledge-based approach (with some artificial intelligence features) during IFMEA. A Failure Mode (FM) is defined as the manner in which a component, assembly, subsystem or system may fail to meet design intent (Design FMEA).

An NHE is the FM of its component’s parent.If there is an unbroken chain of NHS and FMs along the path from an item to the top level, then by definition the NHE has an eventual End Effect (EE). Deleting an NHE along this path violates the integrity of the IFMEA analysis since not all of the events leading up to the end effect are represented. Review the Design FMEA example in Fig.Communication System Receiver Power Supply Battery  Next-Higher-Levels Remark:In Process FMEA, “components” are replaced by “basic operations” such as “machining” “heat treatment”, “stamping” or “prepare laminate”; next indenture levels are different levels of “assembly processes” up to “final assembly” or “service result”.

THE HIGHEST (SYSTEM) LEVEL FM IS THE END EFFECT OF THE SYSTEM

In previous example, “No Communication” is the NHE for Receiver’s FM “Low Receiving Signal”, and at the same time is a FM of the system as a whole. It is also an “End Effect” of the system. PK3 END-EFFECT ALLOCATIONEnd Effects and their Severities should be defined at early stages of system design (at least at the beginning of FMEA).

Once the analysis addresses the End Effect, the “Allocation” process allocates every End Effect to the lowest level component failure cause. For example, the End Effect “No Communication” will be allocated to “Battery Open” and to all other failures which cause communication loss in the system. Remark:This is not an obvious procedure, because at each indenture level

of the system structure, different specialists and experts are involved in the analysis: “Power Supply” level - Electrical engineers “Receiver” level - Electronic engineers “Communication System” level - Project manager and system analysts All of the above people investigate only limited inputs (FM) and give the relevant output (NHE) derived from their best knowledge (based on experience and IFMEA DK).

INTEGRATED FMEA IS A KEY TO SUCCESSFUL FM ANALYSIS

Experience shows that successful FMEA projects require the following: Methodical Data Management Perhaps the most difficult type of data to organize is ideas.

During brainstorming sessions, team members adopt recommendations—all of which need to be recorded for subsequent evaluation. Integrated FMEA requires easy storage and retrieval of recommendations, including their advantages and disadvantages. Each entry expands the knowledge base, and avoids “rediscovering” and reevaluating old ideas. IFMEA includes many data management modules, including failure modes, failure causes, and test methods. You can apply one product’s FMEA knowledge base to any other product, resulting in efficient improvement processes. Commonality FMEA experts develop a library of End Effects, Failure Modes, and Failure Causes that apply to all the company’s products and processes.

For example, a tire manufacturer sells many different sizes of tires.An End Effect such as “low tread life” is common to all tires, regardless of size; an associated failure cause may be “poor quality rubber”. Developing a rich library of FMEA data is a rewarding, though time-consuming task, but it has its rewards. If a new study is required into the problem of “low tread life”, experts can quickly look up previously identified causes—without rehashing the brainstorming and investigation process. Team Work Automated and “intelligent” FMEA must be supported by

the team decision-making process.

Most CAs originate in the human mind, either as a simple good idea, or the result of laborious brainstorming.From there, the path to implementation is best expressed in the easy to remember flow chart: ProblemFailure ModesCorrective ActionCorrective Action determination and Causeschoice, tracking forming team analysis, including analysis understanding getting of possible, of potential suggestions, advantages, Failure Modescheckingdisadvantages and Causesexistingetc. activities and controls Figure 3 - IFMEA DK Implementation Path Developing and Storing CAs (Forming and Storming) Experts and professionals suggest various possible corrective actions for each FM&C. All these potential corrective actions are systematically recorded in the FMEA-KB. Using CAs in Decision Making (Norming) The entries in a library of corrective actions, can be used to quickly evaluate possible solutions, and decide which are appropriate for eliminating FCS.

In addition, several possible CAs can be assigned, and the most effective ones selected. The basic steps of the IFMEA Decision Making procedure are as follows:  the Corrective Action Library, and select a CA. Evaluate and enter advantages, disadvantages and remarks as appropriate for the failure mode or cause.  Repeat to assign as many corrective actions as necessary; any suggestion is welcome and stored after analysis.

Select the most cost-effective corrective actions in accordance with the team’s opinions for the current analysis. Flag the corrective action adopted for each failure cause or mode. IFMEA tracks every step of the previous and current corrective actions implementation, and even maintains comments, enhancement, and objections by members of the team in the FMEA-KB.

Tracking Selected Corrective Actions (Performing) IFMEA provides for tracking the implementation of Corrective Actions, including the following data: responsible person, due date, and percent complete.

GETTING RESULTS WITH

IFMEA

IFMEA uses both stages (DK & PK) of the Knowledge Base to provide useful results and suggestions—impressive reports and graphs that show what improvement efforts are needed. RPN as the Criterion Risk Priority Number (RPN) is the quantitative result of the IFMEA, indicating which failure causes lead to the most likely and most severe End Effects.

IFMEA computes RPNs as a product of Frequency? Severity ? Detectability. Remark:The methodology allows for including additional parameters for RPN evaluation such as CA cost, resources needed, equipment availability, R&R data, etc. ProFMEA as a Tool ALD’s ProFMEA software package was developed exclusively for Integrated FMEA, including the described databases, rules and interfaces, which allow for risk reduction and continuous improvement of product/process based on a comprehensive Knowledge Base and AI elements. To better understand the FMEA elation¬ships at work in their projects, professionals can use any of the following ProFMEA standard reports and features (among dozens others providing various views of the FMEA data):

• Pareto analysis-failure causes sorted by risk priority number
• Testability data-failure modes and assigned test methods •Undetectable failure modes-Failure modes that cannot be detected using existing con¬trols
• Product / Process Tree (PRO-TREE)-listing of the product or process tree in tabular or graphic form
• Fault Tree-Diagram of entire project’s multi-level fault tree in top-down representation—from end effects to failure causes
• Corrective Actions-IFMEA presents the CA that applies to failure causes with the highest RPN. Such implementation ensures obtaining the most improvement for your FMEA investment.
• CA Tracking-IFMEA provides many reports that track the implementation of Corrective Actions, including responsible person, due date, and percent complete.

Team Work (TW), Software (SW) Automation and AI IFMEA is more than

a knowledge mine. Using the accumulated knowledge, IFMEA provides the 12-Step sequence for successful analysis and decision making in process/product (PRO) improvement: Steps 1 -2: IFMEA preparation by Team Work. Steps 3-9: IFMEA Software Preprocessing and Team Work.

REFERENCE LIST

1.  Potential Failure Mode and Effect Analysis (FMEA). Reference Manual. 1995. Chrysler Corporation, Ford Motor Company, General Motors Corporation.
2.  Rafetery, John. 1994. Risk Analysis in Project Management. London: E&FN SPON.
3. Managing for Product Liability Avoidance. 1996. Chicago: CCH Inc.
4.  Bluvband, Zigmund. FMECA - What about the “Quality Assurance” Task? 1989, Proceeding Annual RAM Symposium, Atlanta: IEEE.