[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