[All] Fwd: LRT RE: FAILURE MODES AND EFFECTS ANALYSIS (FMEA) + DESIGN THINKING +

Robert Milligan mill at continuum.org
Fri Jul 2 14:32:15 EDT 2010


FYI
R

Begin forwarded message:

> From: Robert Milligan <mill at continuum.org>
> Date: July 1, 2010 10:18:28 PM GMT-04:00
> To: Darshpreet Bhatti <bdarshpr at region.waterloo.on.ca>
> Cc: Chair Ken Seiling <sken at region.waterloo.on.ca>, CAO Mike Murray <mmike at region.waterloo.on.ca 
> >, Mayor Doug Craig <craigd at cambridge.ca>
> Subject: LRT RE: FAILURE MODES AND EFFECTS ANALYSIS (FMEA) + DESIGN  
> THINKING +
>
> Darshpreet,
>
> This email is in response to recent critical statements to me about  
> your perception of the inadequacy of my LRT approach. In a phone  
> message to you I suggested that I welcomed good criticism but that  
> you needed to raise the bar of your criticism's quality above that  
> on this occasion -- perhaps the lower amount than expected from the  
> Province caused a transference of your feelings. I must say though  
> that I have been generally pleased with your work and openness.
>
> What follows addresses the substance of you comments -- and then some.
>
> As you know, I am of (what I consider) the well-founded view that  
> your current LRT System Design -- if it does not incorporate  
> necessary subtle cost-effective enhancements -- will fail. Then just  
> in case that I am right (and even though you consider that  
> eventuality remote), you should be taking steps to better ensure  
> that the current LRT system design will not fail in ridership,  
> intensification and cost. This is especially because such a failure  
> would be so very dertimental re: wasting of taxpayer's scarce  
> financial resources & our Region's image of very successful  
> innovation. Among other things, knowledge of FMEA will help to  
> constructively prevent with such a situation. What's good for smart  
> businesses, certainly can be good for the Region and its LRT project  
> engineers and planners!  (See below and http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis)
>
> You will notice below that FMEA'S use of the word DESIGN, "focuses  
> on components and subsystems", is the same narrow-focused view as  
> yours -- and yes it is your "convention". However,  the University  
> of Waterloo's (unique in the World) System Design Engineering  
> program does not deal exclusively with the design of "components and  
> subsystems".  Like myself, their view of design & system design is  
> very inclusive, viz. "Solving engineering problems often requires  
> the modification or creation of systems. The process we use to do  
> that is design practice – the skills of creative problem solving,  
> and interdisciplinary teamwork for innovation and synthesis." (See, http://www.systems.uwaterloo.ca/about/syde.html)
>
> Keep in mind that the most successful innovators often break with  
> some "problematic" conventions and rules. I appreciate that neither  
> your profession nor the Region's organizational culture generally  
> encourages such "heretical" thinking so necessary for significant  
> innovative accomplishment & job satisfaction -- and taxpayer return  
> on their investment.
>
> But, unless you are supported by those in the management hierarchy  
> above you (e,g. one Commissioner would likely support you while the  
> other may not), necessary innovation could be personally  
> impossible . (Essentially such innovation would mean including some  
> new IDEAS so as to minimally enhance the current good-but-faulty  
> current system design by: 1) a transit-time-saving Ridership  
> Corridor "overlay", 2) intelligently staging the Intensification  
> Corridors, and 3) synergistically collaborating via mutually- 
> beneficial 3P agreements with CP & GEXR on bridge, underpass, and  
> track sharing.)
>
> Certainly our Regional Chair could play a key role in establishing a  
> more innovative & entrepreneurial organizational culture. But to  
> date he seems too busy with other more important responsibilities  
> (such as getting enough money to proceed with the LRT) to have the  
> time & energy to generate the interest & enthusiasm necessary to  
> strongly support aligning our Regional government with the  
> innovation level of our universities and corporations. (Maybe I need  
> to more innovative myself in how I might encourage him ! )
>
> I pledge to you that I will do all that I can to encourage your  
> political masters that It is in the best interest of the Region and  
> all its major urban centres for these politicians  to direct all  
> staff (and their consultants) to learn to creatively innovate so as  
> to become much more cost-effective in all their work, especially  
> with our LRT system design on which so much is riding.
>
> Certainly the very readable 5-star book, "CHANGE BY DESIGN: How  
> design thinking transforms organizations and inspires innovation"  
> will be useful to all concerned  as the Region struggles to meet the  
> Waterloo Innovation Benchmark in all its great endeavours. See http://www.amazon.ca/Change-Design-Tim-Brown/dp/0061766089
>
> Best wishes,
> Robert
>
> Robert Milligan is a member of Transport Action Ontario (formerly  
> Transport 2000). He has a BSc in math-physics. a Graduate Diploma in  
> Education and has completed many other courses including ones in  
> industrial engineering, operations research and environmental  
> health. He was a high school teacher, business systems analyst and  
> environmental health analyst. Much of his time in retirement is now  
> given freely to public projects, especially those with significant  
> environmental and health features.
>
>
> PS: 1. One key person (not from Cambridge) has claimed very recently  
> that my approach to including Cambridge in the LRT's first stage  
> also is inadequate. Perhaps it has not been interpreted to him  
> adequately by staff. Let me clarify. That first stage approach as it  
> would involve Cambridge is to: 1) have the Ridership Corridor go  
> south to the Ainslie Terminal via the rail right-of-way  
> (intensifying the Dundas/Beverly area) with just-in-time bus  
> connections so that the resulting much less travel time will deal  
> with developing  tri-city traffic jams from the get go; 2) initially  
> use single track with station and between-station passing (as with  
> Ottawa's O-Train LRT) enabled by proven-for-rail Intelligent  
> Transportation System technology but designed to upgrade to 2-tracks  
> when demand merits it (as the O-Train is now doing);  and  3) make  
> Hespler Road into (a less disruptive & less costly single-track with  
> mid-station passing) Intensification Corridor at a later stage when  
> it is ready (eastern hwy 24 by-pass, and motivated developers).  
> Please note that such inclusion of Cambridge would be necessary to  
> be able to offer to CP & GEXR advantages that will allow then to  
> financially justify their participation in 3P collaborative  
> agreements so necessary for the time-locked track, bridge and  
> underpass sharing that will literally save millions of $ in capital  
> costs!!
>
> 2. And please do not demand that I cost out my LRT system design  
> proposed enhancements -- detailed costing is obviously not my area  
> of expertise and I don't have access to the necessary information.  
> But even the average layperson would have sufficient understanding  
> and common sense to realize that the enhancement IDEAS that I am  
> proposing would dramatically both improve performance and decrease  
> costs! I expect not only as much of you but much, much more! A more  
> innovative and entrepreneurial organizational culture may allow that.
>
> Failure modes and effects analysis (FMEA) is methodology to analyze  
> and mitigate potential failures.	
> FAILURE  MODES  AND  EFFECTS  ANALYSIS  (FMEA)
>
> Kenneth Crow
> DRM Associates
>
> © 2002 DRM Associates  All rights reserved. May be used with  
> attribution. Other use prohibited.
>
> Product Development Forum
> NPD Body of Knowledge
> FMEA Workshop
> PD Toolkit (FMEA Software)
> DRM Associates
> Introduction
>
> Customers are placing increased demands on companies for high  
> quality, reliable products. The increasing capabilities and  
> functionality of many products are making it more difficult for  
> manufacturers to maintain the quality and reliability.  
> Traditionally, reliability has been achieved through extensive  
> testing and use of techniques such as probabilistic reliability  
> modeling. These are techniques done in the late stages of  
> development. The challenge is to design in quality and reliability  
> early in the development cycle.
>
> Failure Modes and Effects Analysis (FMEA) is methodology for  
> analyzing potential reliability problems early in the development  
> cycle where it is easier to take actions to overcome these issues,  
> thereby enhancing reliability through design. FMEA is used to  
> identify potential failure modes, determine their effect on the  
> operation of the product, and identify actions to mitigate the  
> failures. A crucial step is anticipating what might go wrong with a  
> product. While anticipating every failure mode is not possible, the  
> development team should formulate as extensive a list of potential  
> failure modes as possible.
>
> The early and consistent use of FMEAs in the design process allows  
> the engineer to design out failures and produce reliable, safe, and  
> customer pleasing products. FMEAs also capture historical  
> information for use in future product improvement.
>
> Types of FMEA's
>
> There are several types of FMEAs, some are used much more often than  
> others. FMEAs should always be done whenever failures would mean  
> potential harm or injury to the user of the end item being designed.  
> The types of FMEA are:
>
> System - focuses on global system functions
> Design - focuses on components and subsystems
> Process - focuses on manufacturing and assembly processes
> Service - focuses on service functions
> Software - focuses on software functions
> FMEA Usage
>
> Historically, engineers have done a good job of evaluating the  
> functions and the form of products and processes in the design  
> phase. They have not always done so well at designing in reliability  
> and quality. Often the engineer uses safety factors as a way of  
> making sure that the design will work and protected the user against  
> product or process failure. As described in a recent article:
>
> "A large safety factor does not necessarily translate into a  
> reliable product. Instead, it often leads to an overdesigned product  
> with reliability problems."
> Failure Analysis Beats Murphey's Law
> Mechanical Engineering , September 1993
> FMEA's provide the engineer with a tool that can assist in providing  
> reliable, safe, and customer pleasing products and processes. Since  
> FMEA help the engineer identify potential product or process  
> failures, they can use it to:
>
> Develop product or process requirements that minimize the likelihood  
> of those failures.
> Evaluate the requirements obtained from the customer or other  
> participants in the design process to ensure that those requirements  
> do not introduce potential failures.
> Identify design characteristics that contribute to failures and  
> design them out of the system or at least minimize the resulting  
> effects.
> Develop methods and procedures to develop and test the product/ 
> process to ensure that the failures have been successfully eliminated.
> Track and manage potential risks in the design. Tracking the risks  
> contributes to the development of corporate memory and the success  
> of future products as well.
> Ensure that any failures that could occur will not injure or  
> seriously impact the customer of the product/process.
> Benefits of FMEA
>
> FMEA is designed to assist the engineer improve the quality and  
> reliability of design. Properly used the FMEA provides the engineer  
> several benefits. Among others, these benefits include:
>
> Improve product/process reliability and quality
> Increase customer satisfaction
> Early identification and elimination of potential product/process  
> failure modes
> Prioritize product/process deficiencies
> Capture engineering/organization knowledge
> Emphasizes problem prevention
> Documents risk and actions taken to reduce risk
> Provide focus for improved testing and development
> Minimizes late changes and associated cost
> Catalyst for teamwork and idea exchange between functions
> FMEA Timing
>
> The FMEA is a living document. Throughout the product development  
> cycle change and updates are made to the product and process. These  
> changes can and often do introduce new failure modes. It is  
> therefore important to review and/or update the FMEA when:
>
> A new product or process is being initiated (at the beginning of the  
> cycle).
> Changes are made to the operating conditions the product or process  
> is expected to function in.
> A change is made to either the product or process design. The  
> product and process are inter-related. When the product design is  
> changed the process is impacted and vice-versa.
> New regulations are instituted.
> Customer feedback indicates problems in the product or process.
> FMEA Procedure
>
> The process for conducting an FMEA is straightforward. The basic  
> steps are outlined below.
>
> Describe the product/process and its function. An understanding of  
> the product or process under consideration is important to have  
> clearly articulated. This understanding simplifies the process of  
> analysis by helping the engineer identify those product/process uses  
> that fall within the intended function and which ones fall outside.  
> It is important to consider both intentional and unintentional uses  
> since product failure often ends in litigation, which can be costly  
> and time consuming.
>
> Create a Block Diagram of the product or process. A block diagram of  
> the product/process should be developed. This diagram shows major  
> components or process steps as blocks connected together by lines  
> that indicate how the components or steps are related. The diagram  
> shows the logical relationships of components and establishes a  
> structure around which the FMEA can be developed. Establish a Coding  
> System to identify system elements. The block diagram should always  
> be included with the FMEA form.
>
> Complete the header on the FMEA Form worksheet: Product/System,  
> Subsys./Assy., Component, Design Lead, Prepared By, Date, Revision  
> (letter or number), and Revision Date. Modify these headings as  
> needed.
>
>
> Use the diagram prepared above to begin listing items or functions.  
> If items are components, list them in a logical manner under their  
> subsystem/assembly based on the block diagram.
>
> Identify Failure Modes. A failure mode is defined as the manner in  
> which a component, subsystem, system, process, etc. could  
> potentially fail to meet the design intent. Examples of potential  
> failure modes include:
> Corrosion
> Hydrogen embrittlement
> Electrical Short or Open
> Torque Fatigue
> Deformation
> Cracking
>
> A failure mode in one component can serve as the cause of a failure  
> mode in another component. Each failure should be listed in  
> technical terms. Failure modes should be listed for function of each  
> component or process step. At this point the failure mode should be  
> identified whether or not the failure is likely to occur. Looking at  
> similar products or processes and the failures that have been  
> documented for them is an excellent starting point.
>
> Describe the effects of those failure modes. For each failure mode  
> identified the engineer should determine what the ultimate effect  
> will be. A failure effect is defined as the result of a failure mode  
> on the function of the product/process as perceived by the customer.  
> They should be described in terms of what the customer might see or  
> experience should the identified failure mode occur. Keep in mind  
> the internal as well as the external customer. Examples of failure  
> effects include:
> Injury to the user
> Inoperability of the product or process
> Improper appearance of the product or process
> Odors
> Degraded performance
> Noise
>
> Establish a numerical ranking for the severity of the effect. A  
> common industry standard scale uses 1 to represent no effect and 10  
> to indicate very severe with failure affecting system operation and  
> safety without warning. The intent of the ranking is to help the  
> analyst determine whether a failure would be a minor nuisance or a  
> catastrophic occurrence to the customer. This enables the engineer  
> to prioritize the failures and address the real big issues first.
>
> Identify the causes for each failure mode. A failure cause is  
> defined as a design weakness that may result in a failure. The  
> potential causes for each failure mode should be identified and  
> documented. The causes should be listed in technical terms and not  
> in terms of symptoms. Examples of potential causes include:
> Improper torque applied
> Improper operating conditions
> Contamination
> Erroneous algorithms
> Improper alignment
> Excessive loading
> Excessive voltage
>
> Enter the Probability factor. A numerical weight should be assigned  
> to each cause that indicates how likely that cause is (probability  
> of the cause occuring). A common industry standard scale uses 1 to  
> represent not likely and 10 to indicate inevitable.
>
> Identify Current Controls (design or process). Current Controls  
> (design or process) are the mechanisms that prevent the cause of the  
> failure mode from occurring or which detect the failure before it  
> reaches the Customer. The engineer should now identify testing,  
> analysis, monitoring, and other techniques that can or have been  
> used on the same or similar products/processes to detect failures.  
> Each of these controls should be assessed to determine how well it  
> is expected to identify or detect failure modes. After a new product  
> or process has been in use previously undetected or unidentified  
> failure modes may appear. The FMEA should then be updated and plans  
> made to address those failures to eliminate them from the product/ 
> process.
>
> Determine the likelihood of Detection. Detection is an assessment of  
> the likelihood that the Current Controls (design and process) will  
> detect the Cause of the Failure Mode or the Failure Mode itself,  
> thus preventing it from reaching the Customer. Based on the Current  
> Controls, consider the likelihood of Detection using the following  
> table for guidance.
>
> Review Risk Priority Numbers (RPN). The Risk Priority Number is a  
> mathematical product of the numerical Severity, Probability, and  
> Detection ratings:
>          RPN = (Severity) x (Probability) x (Detection)
> The RPN is used to prioritize items than require additional quality  
> planning or action.
>
> Determine Recommended Action(s) to address potential failures that  
> have a high RPN. These actions could include specific inspection,  
> testing or quality procedures; selection of different components or  
> materials; de-rating; limiting environmental stresses or operating  
> range; redesign of the item to avoid the failure mode; monitoring  
> mechanisms; performing preventative maintenance; and inclusion of  
> back-up systems or redundancy.
>
> Assign Responsibility and a Target Completion Date for these  
> actions. This makes responsibility clear-cut and facilitates tracking.
>
> Indicate Actions Taken. After these actions have been taken, re- 
> assess the severity, probability and detection and review the  
> revised RPN's. Are any further actions required?
>
> Update the FMEA as the design or process changes, the assessment  
> changes or new information becomes known.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gren.ca/pipermail/all_gren.ca/attachments/20100702/e3eb1eaa/attachment.html>


More information about the All mailing list