1,217
17
Essay, 13 pages (3500 words)

Knowledge base approach to integrated fmea

KNOWLEDGE BASE APPROACH TO INTEGRATED FMEA If you want snapshots, use a spreadsheet. If you want continuous improvement, use a Knowledge Base Approach KEY WORDS Artificial Intelligence, Continuous Improvement, Corrective Action , Risk Priority Number SUMMARY Integrated Failure Mode and Effects Analysis (IFMEA) is an interdisciplinary methodology for product and process improvement. The methodology employs the fundamentals of artificial intelligence and knowledge mine acquisition to develop a comprehensive decision making environment. The benefits of IFMEA include identification of controls and elimination of potential failures. INTRODUCTION To compete in today’s marketplace, designers and manufacturers must eliminate, or at least decrease, the impact of all severe malfunctions and possible failures from their products and manufacturing processes.

Moreover, modern standards and regulations (QS-9000, GMP, FAR) require designers and manufacturers to formally demonstrate that all potential malfunctions are analyzed, controlled, and their risks have been minimized (Chrysler Corporation 1995, CCH Inc. 996). Failure Mode and Effects Analysis (FMEA) is a systematic set of activities—crossfunctional team work—intended to identify, investigate and apply better control and corrective actions to minimize a risk of potential concern. The real objective of FMEA may be expressed as follows: not only to avoid risk but also to recognize it, price it, minimize it, and maybe even to sell it (Rafetery 1994, Bluvband 1989). Up-front time devoted to comprehensive FMEA, at the stages when roducts/processes changes and improvements can be easily and inexpensively implemented, will obviate late change crises. Integrated Failure Mode and Effects Analysis (IFMEA) is based on the understanding that artificial intelligence (AI) can be applied to product/process improvement only if accompanied by a customized knowledge base that organizes, not hinders, the improvement effort.

Most AI systems seek to mimic human intelligence by making sense out of ambiguous data, or 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 enhancing 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. Fig. 1 shows DK as part of the FMEA KB. Figure 1.

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). DK1. 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.

Component / Process Element Prepare LaminateDrill Holes FailureModes Panel Edge Is Weak Panel Is Damaged FailureCauses Blades Not Set Figure 2 – The Structure of Component Library Stage of DK DK2: CORRECTIVE (AND PREVENTIVE) ACTIONS LIBRARY Note that there are two different sources for knowledge of failure modes and causes (see Fig. 1): failure reporting and failure analysis, leading to Corrective Action (CA) and Preventive Action (PA), respectively. Considering that potential (from analysis) or acted (from FRACAS) failure modes are treated as a reality, we will refer to both CA and PA stored in the KB as “ Corrective Action”. In fact, there is a “ many-to-many” relationship between CAs and Failure Modes & Causes (FM&Cs): •For one FM&C, there can be many CAs •One CA may be applicable to many FM&Cs There are three different sources for these relationships: Physical Evidence—available when previous FMEA studies have proven the relationship between a FM&C and a CA.

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.

DK3: CA DATABASE DESCRIPTION DK3 contains the definitions of potential 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 stationIncreases probability of detecting defectCreates overcrowding in current factoryFabrication ManagerMay require completely new factory layout10/02/97 Place boards in protective packageReduces in-transit damageIncreased cost and volumeShipping managerGet quotes from shipping co.

1/03/97 Do not hire a color blind person for this jobEliminates problems associated with color codesPersonnel or discrimination issuesPersonnel, manufacturing managersCheck legal dept. 05/05/97 DK4: END EFFECT AND ITS SEVERITY LIBRARY DK4 library lists failure modes for the top level item (i. e. , the whole process or product).

Identification of End Effects and assessment of their Severities are extremely important. As a rule, these functions are performed by project managers and include customers’ opinions. End Effect Library ItemEnd EffectSeverity LOSS OF COMMUNICATION9 2HIGH DISTORTION6 3INCORRECT COLOR1 4NO AUDIO ALARM8 Remark: Severity is an assessment of the seriousness of the effect. Severity should be estimated on a “ 1” to “ 10” scale (see table below). EffectRanking Hazardous without warning10 Hazardous with warning9 Very High8 High7 Moderate6 Low5 Very Low4 Minor3 Very Minor2 None1 DK5: TEST METHODS LIBRARY The Test Method library is a listing of test methods or procedures. Each method is characterized by test level, time required, test type, number of persons needed, etc.

Test Method LibraryTest NameTest LevelInterval TimeTest TimeSkill NeededTest TypeTime to Mission EndNo. of Person Needed RX001Organizational2. 55HighBIT381 TX001Organizational6. 08HighBITE54. 52 In practice it is important to keep additional independent libraries of test levels and test types: DK5. 1: TEST LEVEL LIBRARY DK5.

1 lists locations where the tests are conducted, including repair levels (e. g. , organizational, intermediate, depot), physical locations and development and manufacturing phases. DK5. 2 TEST TYPE LIBRARY DK5. 2 describes the nature of the test.

Examples include built-in test, self-test, and routine maintenance. Test Type Library Test Type CodeTest Type Description 1BIT 2BITE 3Manual 4Passive 5Visual Inspection 6Non-destructive DK6: DETECTABILITY LIBRARY 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.

20. 30 7A poor chance to detect defect existence. 30. 40 6Controls may detect the existence of a defect. 40.

50 5Controls can detect the existence of a defect. 50. 60 A good chance to detect the existence of a defect. 60. 70 3A very good chance to detect defect existence. 70.

80 2Controls almost certainly detect defect existence. 80. 90 1Controls certainly detect defect existence. 901. 00 DK7: CURRENT CONTROLS DK7 includes controls used to detect failures, including warning lights, gages, and filters, all kinds of preventive actions, etc.

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 an 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 NHEs 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.

3 for a battery’s FM “ open”. One can define a Next-Higher-Effect (NHE) “ No Power” for the Power Supply. In turn “ No Power” is a FM of Power Supply, causing the NHE “ Low Receiving Signal” which in turn is the FM of Receiver causing NHE “ No Communication”—a higher system-level failure effect. Communication System Receiver Power Supply Battery Fig. 3. 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”.

PK2. 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 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 simply 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 determinationand Causeschoice, tracking forming teamanalysis, including analysis understandinggetting of possible, of potentialsuggestions, 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: 1. Access the Corrective Action Library, and select a CA. Evaluate and enter advantages, disadvantages and remarks as appropriate for the failure mode or cause. 2. 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. 4. 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. Figure 4 – CA Progress by DateIn addition, the CA library must include the following data to track implementation. DatePercent Performed (%)Action Processed 1/10/9620Space utilization drawing 4/10/9660Gather and analyze employee input 9/10/9680Design Review 2/1/97100Move UI station 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 apply 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.

Steps 10-11: IFMEA straight Software Processing. Step 12: CA Final Decision Making and Implementation. STEP-BY-STEP IFMEA FLOW Step 1(TW)Identify the PRO End Effects and Severities (DK4) Step 2(TW/SW)Define the PRO-TREE (or import it). Step 3(SW)Choose appropriate Failure Modes and Causes from DK1 and assign them to PRO-TREE (use of DK1, PK1 & PK2). Step 4(SW)Retrieve pre-defined options (DK2 & DK3).

Step 5(HW)Study, select and add new CA candidates (DK2& DK3) Step 6(SW)Retrieve appropriate TEST methods (DK5, DK6). Step 7(HW)Study, select and add new TESTS (DK5, DK6). Step 8(SW)Retrieve appropriate Current Controls (DK7) Step 9(HW)Study, select and add new Controls (DK7) Step 10(SW)Automatic and “ intelligent” analysis using the “ NHE Chain” (rule PK1). Step 11 (SW)“ Intelligent” allocating each End Effect and Severity to the lowest level Causes and computing the RPN, (applying PK2 & PK3 rules). Step 12(TW/SW)Review the whole FMEA. Finalize, implement and track the Implementation progress CONCLUSION In this article, we have demonstrated the importance of Integrated Failure Mode and Effects Analysis (IFMEA), which applies artificial intelligence approach and knowledge base construction to product and process improvement.

Furthermore, we have outlined the critical elements of in both AI and KB for successful application to improvement programs. Knowledge Base—a database that encompasses two types of knowledge: procedural and declarative, in the IFMEA context, includes proposals for eliminating problems, and the advantages and disadvantages of each proposal, rules for developing the NHE chain, entries about Testing and Detectability, Expert’ concepts and experience during the product/process improvement effort. To be effective, a knowledge base must store information in a manner that is accessible, comprehensible, and applicable to downstream improvement efforts. Artificial Intelligence—The AI side of IFMEA provides recommendations based on the information in the KB, including tables, graphs, likelihood of success, and other decision-making information. The IFMEA approach ensures rapid product/process improvement, and reduces time to market, enhancing the effectiveness and the competitiveness of those companies that implement it.

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.

Thank's for Your Vote!
Knowledge base approach to integrated fmea. Page 1
Knowledge base approach to integrated fmea. Page 2
Knowledge base approach to integrated fmea. Page 3
Knowledge base approach to integrated fmea. Page 4
Knowledge base approach to integrated fmea. Page 5
Knowledge base approach to integrated fmea. Page 6
Knowledge base approach to integrated fmea. Page 7
Knowledge base approach to integrated fmea. Page 8
Knowledge base approach to integrated fmea. Page 9

This work, titled "Knowledge base approach to integrated fmea" was written and willingly shared by a fellow student. This sample can be utilized as a research and reference resource to aid in the writing of your own work. Any use of the work that does not include an appropriate citation is banned.

If you are the owner of this work and don’t want it to be published on AssignBuster, request its removal.

Request Removal
Cite this Essay

References

AssignBuster. (2022) 'Knowledge base approach to integrated fmea'. 27 September.

Reference

AssignBuster. (2022, September 27). Knowledge base approach to integrated fmea. Retrieved from https://assignbuster.com/knowledge-base-approach-to-integrated-fmea/

References

AssignBuster. 2022. "Knowledge base approach to integrated fmea." September 27, 2022. https://assignbuster.com/knowledge-base-approach-to-integrated-fmea/.

1. AssignBuster. "Knowledge base approach to integrated fmea." September 27, 2022. https://assignbuster.com/knowledge-base-approach-to-integrated-fmea/.


Bibliography


AssignBuster. "Knowledge base approach to integrated fmea." September 27, 2022. https://assignbuster.com/knowledge-base-approach-to-integrated-fmea/.

Work Cited

"Knowledge base approach to integrated fmea." AssignBuster, 27 Sept. 2022, assignbuster.com/knowledge-base-approach-to-integrated-fmea/.

Get in Touch

Please, let us know if you have any ideas on improving Knowledge base approach to integrated fmea, or our service. We will be happy to hear what you think: [email protected]