<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Improving Product Robustness 101</title>
	<atom:link href="http://www.shipulski.com/2009/12/24/improving-product-robustness-101/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.shipulski.com/2009/12/24/improving-product-robustness-101/</link>
	<description>Innovation, Product Development, Design</description>
	<lastBuildDate>Mon, 26 Jul 2010 02:06:14 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: Al Dickinson</title>
		<link>http://www.shipulski.com/2009/12/24/improving-product-robustness-101/comment-page-1/#comment-235</link>
		<dc:creator>Al Dickinson</dc:creator>
		<pubDate>Thu, 25 Mar 2010 15:44:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.shipulski.com/?p=436#comment-235</guid>
		<description>This is a sensible approach to achieving improved QRD.

I especially like your thinking re &quot;robustness surrogates&quot;.  One form of &quot;broken&quot; product is unacceptable degraded performance, which I think is assumed in your article.  I expect my car&#039;s accessories will get noisier at high mileage, but if they degrade too fast and I&#039;m within the warranty period, I&#039;m going to take it in for repair, even if the intended function remains intact (I still have full power steering assist, for example).  You can apply your same robustness surrogate thinking to degraded performance as well.

In these cases you&#039;re not producing a &quot;broken&quot; product, but you still need to proceed cautiously in reproducing the field failure.  One approach is degradation analysis (http://www.weibull.com/LifeDataWeb/degradation_analysis.htm).  Say you&#039;ve determined a threshold of acceptable degraded performance (perhaps via the Quality Loss Function) and know the stresses and cycles that would simulate 1X life.  Your objective is to simulate the field failure as quickly as possible.  As you say, you want to produce the failure in minutes or hours.  If you understand the physics of failure (or degradation), carefully select experimental accelerating stress factors and levels (you want to hatch the chick faster... no hard-boiled eggs!), and apply an appropriate life model to the degradation test data, you can EXTRAPOLATE when actual 1X (or higher) life occurs.  You would validate your degradation analysis by continuing to degrade some parts until a complete duplication of the field failure is realized (confirmed via a method such as Design Review Based on Test Results - DRBTR).  Now, you&#039;re home free.  You won&#039;t have to precisely duplicate field failure during optimization because the degradation analysis gave you good anticipatory ability, allowing you to efficiently verify design modifications targeted to improve QRD.

Hope this adds some value to the conversation...</description>
		<content:encoded><![CDATA[<p>This is a sensible approach to achieving improved QRD.</p>
<p>I especially like your thinking re &#8220;robustness surrogates&#8221;.  One form of &#8220;broken&#8221; product is unacceptable degraded performance, which I think is assumed in your article.  I expect my car&#8217;s accessories will get noisier at high mileage, but if they degrade too fast and I&#8217;m within the warranty period, I&#8217;m going to take it in for repair, even if the intended function remains intact (I still have full power steering assist, for example).  You can apply your same robustness surrogate thinking to degraded performance as well.</p>
<p>In these cases you&#8217;re not producing a &#8220;broken&#8221; product, but you still need to proceed cautiously in reproducing the field failure.  One approach is degradation analysis (<a href="http://www.weibull.com/LifeDataWeb/degradation_analysis.htm" rel="nofollow">http://www.weibull.com/LifeDataWeb/degradation_analysis.htm</a>).  Say you&#8217;ve determined a threshold of acceptable degraded performance (perhaps via the Quality Loss Function) and know the stresses and cycles that would simulate 1X life.  Your objective is to simulate the field failure as quickly as possible.  As you say, you want to produce the failure in minutes or hours.  If you understand the physics of failure (or degradation), carefully select experimental accelerating stress factors and levels (you want to hatch the chick faster&#8230; no hard-boiled eggs!), and apply an appropriate life model to the degradation test data, you can EXTRAPOLATE when actual 1X (or higher) life occurs.  You would validate your degradation analysis by continuing to degrade some parts until a complete duplication of the field failure is realized (confirmed via a method such as Design Review Based on Test Results &#8211; DRBTR).  Now, you&#8217;re home free.  You won&#8217;t have to precisely duplicate field failure during optimization because the degradation analysis gave you good anticipatory ability, allowing you to efficiently verify design modifications targeted to improve QRD.</p>
<p>Hope this adds some value to the conversation&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike</title>
		<link>http://www.shipulski.com/2009/12/24/improving-product-robustness-101/comment-page-1/#comment-131</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Wed, 06 Jan 2010 03:23:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.shipulski.com/?p=436#comment-131</guid>
		<description>Thanks, Jack.  Your comment adds much needed substance to the arguement.  Mike</description>
		<content:encoded><![CDATA[<p>Thanks, Jack.  Your comment adds much needed substance to the arguement.  Mike</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jack Ring</title>
		<link>http://www.shipulski.com/2009/12/24/improving-product-robustness-101/comment-page-1/#comment-122</link>
		<dc:creator>Jack Ring</dc:creator>
		<pubDate>Thu, 24 Dec 2009 20:20:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.shipulski.com/?p=436#comment-122</guid>
		<description>Thank you for this. No doubt these techniques can be useful and certainly better than much of the current practice. 
But why wait to reduce warranty costs until the losses start occurring? An appropriate application of systems engineering, www.incose.org, up front can preclude most of the warranty claims (and the not as visible but much more pernicious badmouthing). Further, FMEA, properly done, focuses on system integrity balancing, a more insightful technique than risk-oriented analysis.  Even more powerful is to consider not only failures but all causes of less than optimal performance throughout all conditions of operation. Some people now refer to this as resiliency rather than robustness, http://www.incose.org/practice/techactivities/wg/rswg/
Anyway, keep up the good work and strive to become continually better.</description>
		<content:encoded><![CDATA[<p>Thank you for this. No doubt these techniques can be useful and certainly better than much of the current practice.<br />
But why wait to reduce warranty costs until the losses start occurring? An appropriate application of systems engineering, <a href="http://www.incose.org" rel="nofollow">http://www.incose.org</a>, up front can preclude most of the warranty claims (and the not as visible but much more pernicious badmouthing). Further, FMEA, properly done, focuses on system integrity balancing, a more insightful technique than risk-oriented analysis.  Even more powerful is to consider not only failures but all causes of less than optimal performance throughout all conditions of operation. Some people now refer to this as resiliency rather than robustness, <a href="http://www.incose.org/practice/techactivities/wg/rswg/" rel="nofollow">http://www.incose.org/practice/techactivities/wg/rswg/</a><br />
Anyway, keep up the good work and strive to become continually better.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
