<?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 for No MTBF</title>
	<atom:link href="http://nomtbf.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://nomtbf.com</link>
	<description>A site devoted to the eradication of the misuse of MTBF</description>
	<lastBuildDate>Fri, 11 May 2012 21:19:11 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>Comment on What should we use instead of MTBF? by Fred Schenkelberg</title>
		<link>http://nomtbf.com/2011/10/what-instead-mtbf/#comment-360</link>
		<dc:creator>Fred Schenkelberg</dc:creator>
		<pubDate>Fri, 11 May 2012 21:19:11 +0000</pubDate>
		<guid isPermaLink="false">http://nomtbf.com/?p=83#comment-360</guid>
		<description>Hi Greg and welcome back to the Reliability side of things.

Thanks for the comments and I agree, helping to translate reliability into number of returns during warranty (or better the cost of warranty) is sound advice.

Let us know of any local victories with the eradication of MTBF. And, of course, any ideas that may support the cause.

cheers,

Fred</description>
		<content:encoded><![CDATA[<p>Hi Greg and welcome back to the Reliability side of things.</p>
<p>Thanks for the comments and I agree, helping to translate reliability into number of returns during warranty (or better the cost of warranty) is sound advice.</p>
<p>Let us know of any local victories with the eradication of MTBF. And, of course, any ideas that may support the cause.</p>
<p>cheers,</p>
<p>Fred</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What should we use instead of MTBF? by Greg McLean</title>
		<link>http://nomtbf.com/2011/10/what-instead-mtbf/#comment-359</link>
		<dc:creator>Greg McLean</dc:creator>
		<pubDate>Fri, 11 May 2012 20:35:17 +0000</pubDate>
		<guid isPermaLink="false">http://nomtbf.com/?p=83#comment-359</guid>
		<description>I recently found my way back to Reliability (I went over to the dark Quality side for a dozen years) and I was surprised to see how little it has changed.  This is a revolution that is worth fighting for!
I have customers who demand to see the MTBF, then they want me to put the early life failures back into the equation because they need to have the “complete picture” ... then they ask why did the MTBF go up???   (even with a mixed Weibull model)
I am a huge advocate of stating the reliability at a specific time.  As you say, it is positive, but I find the best trait is that it is easy for the audience (once they catch on).  It tells them how many will survive in a time period that matters (e.g., warranty) and it is easy to put multiple pieces together to get a system reliability (and it doesn’t matter how the different failures are distributed!)</description>
		<content:encoded><![CDATA[<p>I recently found my way back to Reliability (I went over to the dark Quality side for a dozen years) and I was surprised to see how little it has changed.  This is a revolution that is worth fighting for!<br />
I have customers who demand to see the MTBF, then they want me to put the early life failures back into the equation because they need to have the “complete picture” &#8230; then they ask why did the MTBF go up???   (even with a mixed Weibull model)<br />
I am a huge advocate of stating the reliability at a specific time.  As you say, it is positive, but I find the best trait is that it is easy for the audience (once they catch on).  It tells them how many will survive in a time period that matters (e.g., warranty) and it is easy to put multiple pieces together to get a system reliability (and it doesn’t matter how the different failures are distributed!)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Acceleration factors by Natasha Rayetsky</title>
		<link>http://nomtbf.com/2012/05/acceleration-factors/#comment-348</link>
		<dc:creator>Natasha Rayetsky</dc:creator>
		<pubDate>Tue, 08 May 2012 06:13:50 +0000</pubDate>
		<guid isPermaLink="false">http://nomtbf.com/?p=219#comment-348</guid>
		<description>Hi Fred,

I had no knowledge about Norris Landzberg and Peck’s equation, I&#039;ll go learn about it.
Of course, I haven&#039;t assumed to use temperature acceleration for all the failure mechanisms. I just didn&#039;t know any other model for temperature-induced failure mechanisms except Arrhenius.
I&#039;ll adopt the overall approach you suggested. Thank you!</description>
		<content:encoded><![CDATA[<p>Hi Fred,</p>
<p>I had no knowledge about Norris Landzberg and Peck’s equation, I&#8217;ll go learn about it.<br />
Of course, I haven&#8217;t assumed to use temperature acceleration for all the failure mechanisms. I just didn&#8217;t know any other model for temperature-induced failure mechanisms except Arrhenius.<br />
I&#8217;ll adopt the overall approach you suggested. Thank you!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Acceleration factors by Fred Schenkelberg</title>
		<link>http://nomtbf.com/2012/05/acceleration-factors/#comment-342</link>
		<dc:creator>Fred Schenkelberg</dc:creator>
		<pubDate>Mon, 07 May 2012 15:38:04 +0000</pubDate>
		<guid isPermaLink="false">http://nomtbf.com/?p=219#comment-342</guid>
		<description>Hi Natasha,

I fully understand the problem and constraints. Here&#039;s what I suggest - and it&#039;s not strictly by the book, yet closer. Talk to your lead designers about what is expected to fail and under what conditions. Gather information about the use environment, not just the limits, what happens every day. And, make an educated guess or two.

If your environment includes a very large change in temperature every day (or hour), then thermal cycling may the the stress to focus on and plan your testing acceleration factor around solder joint fatigue (modified Norris Landzberg). If thermal cycling isn&#039;t a big deal (over 20°C per cycle) then consider the thermal exposure and humidity... if in hot humid conditions - then corrosion, metal migration, etc. may play the dominant role. Then plan the testing around Peck&#039;s equation. If both, then do both.

For motors - they are often easier to get samples and set up a separate test. The motors, if in series, reliability wise - will need a higher reliability target, and more samples or longer run time for demonstration. If you have to use them within the system - then hopefully you can load the motors while doing one or more of the other tests to get the sample size up.

Unfortunately, there just isn&#039;t a magic temperature acceleration factor for all failure mechanisms - some failures do not care about the temperature, as they fail at the hands of other stresses.

A little creativity and focus on expected failure mechanisms may move your testing program along.

Cheers,

Fred</description>
		<content:encoded><![CDATA[<p>Hi Natasha,</p>
<p>I fully understand the problem and constraints. Here&#8217;s what I suggest &#8211; and it&#8217;s not strictly by the book, yet closer. Talk to your lead designers about what is expected to fail and under what conditions. Gather information about the use environment, not just the limits, what happens every day. And, make an educated guess or two.</p>
<p>If your environment includes a very large change in temperature every day (or hour), then thermal cycling may the the stress to focus on and plan your testing acceleration factor around solder joint fatigue (modified Norris Landzberg). If thermal cycling isn&#8217;t a big deal (over 20°C per cycle) then consider the thermal exposure and humidity&#8230; if in hot humid conditions &#8211; then corrosion, metal migration, etc. may play the dominant role. Then plan the testing around Peck&#8217;s equation. If both, then do both.</p>
<p>For motors &#8211; they are often easier to get samples and set up a separate test. The motors, if in series, reliability wise &#8211; will need a higher reliability target, and more samples or longer run time for demonstration. If you have to use them within the system &#8211; then hopefully you can load the motors while doing one or more of the other tests to get the sample size up.</p>
<p>Unfortunately, there just isn&#8217;t a magic temperature acceleration factor for all failure mechanisms &#8211; some failures do not care about the temperature, as they fail at the hands of other stresses.</p>
<p>A little creativity and focus on expected failure mechanisms may move your testing program along.</p>
<p>Cheers,</p>
<p>Fred</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Acceleration factors by Natasha Rayetsky</title>
		<link>http://nomtbf.com/2012/05/acceleration-factors/#comment-341</link>
		<dc:creator>Natasha Rayetsky</dc:creator>
		<pubDate>Mon, 07 May 2012 13:18:16 +0000</pubDate>
		<guid isPermaLink="false">http://nomtbf.com/?p=219#comment-341</guid>
		<description>Thank you for your explanation! 
Your answer is correct theoretically, and I wish I had the resources for testing the system &quot;by the book&quot;. But, as usual in the industry - especially in small companies such as the one I work in - I need to work under limitation of resources. The actual need is to perform Reliability Demonstration Test for the whole system. The required test time to show, with the required confidence level, that the system MTBF (Theta, if you prefer) is sufficient, is too long, when there is a limitation of available number of systems, and time allocated to the test. 
I was looking for possible acceleration factors for this purpose. The reliability prediction pareto shows that the parts most affecting the failure rates are the bearings and motors, and the electrical cards - so I assumed to propose acceleration by increased/unbalanced load for the moving parts, and by temperature for the cards - but I need to decide which temperature acceleration model to use. 
No FMEA was conducted during the design process, so no significant inputs about failure modes are available.
Any advise under the given circumstances will be welcome with many thanks.

Natasha</description>
		<content:encoded><![CDATA[<p>Thank you for your explanation!<br />
Your answer is correct theoretically, and I wish I had the resources for testing the system &#8220;by the book&#8221;. But, as usual in the industry &#8211; especially in small companies such as the one I work in &#8211; I need to work under limitation of resources. The actual need is to perform Reliability Demonstration Test for the whole system. The required test time to show, with the required confidence level, that the system MTBF (Theta, if you prefer) is sufficient, is too long, when there is a limitation of available number of systems, and time allocated to the test.<br />
I was looking for possible acceleration factors for this purpose. The reliability prediction pareto shows that the parts most affecting the failure rates are the bearings and motors, and the electrical cards &#8211; so I assumed to propose acceleration by increased/unbalanced load for the moving parts, and by temperature for the cards &#8211; but I need to decide which temperature acceleration model to use.<br />
No FMEA was conducted during the design process, so no significant inputs about failure modes are available.<br />
Any advise under the given circumstances will be welcome with many thanks.</p>
<p>Natasha</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on MTBF free Availability by Productivity and Reliability Based Maintenance, Since these based on the reliability, How can we describe tihs?</title>
		<link>http://nomtbf.com/2009/05/mtbf-free-availability/#comment-222</link>
		<dc:creator>Productivity and Reliability Based Maintenance, Since these based on the reliability, How can we describe tihs?</dc:creator>
		<pubDate>Mon, 09 Apr 2012 11:59:56 +0000</pubDate>
		<guid isPermaLink="false">http://nomtbf.com/?p=67#comment-222</guid>
		<description>I follow up any data from you.</description>
		<content:encoded><![CDATA[<p>I follow up any data from you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on MTBF free Availability by Stephanie</title>
		<link>http://nomtbf.com/2009/05/mtbf-free-availability/#comment-7</link>
		<dc:creator>Stephanie</dc:creator>
		<pubDate>Wed, 08 Feb 2012 20:19:04 +0000</pubDate>
		<guid isPermaLink="false">http://nomtbf.com/?p=67#comment-7</guid>
		<description>Thanks so much for the great information. I always love to read more about the industry. 
Thank you.</description>
		<content:encoded><![CDATA[<p>Thanks so much for the great information. I always love to read more about the industry.<br />
Thank you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What should we use instead of MTBF? by Bjarni Ellert Ísleifsson, CMRP</title>
		<link>http://nomtbf.com/2011/10/what-instead-mtbf/#comment-2</link>
		<dc:creator>Bjarni Ellert Ísleifsson, CMRP</dc:creator>
		<pubDate>Sun, 15 Jan 2012 03:24:33 +0000</pubDate>
		<guid isPermaLink="false">http://nomtbf.com/?p=83#comment-2</guid>
		<description>Hi Fred,

Thank you very much for the like on my post : http://bjarniis.wordpress.com/2012/01/08/logic-will-get-you-from-a-to-b-imagination-will-take-you-everywhere-albert-einstein/ 

I would like to say I like that you would like to focus on positives rather than negatives. Uptime (reliability) is positive MTBF is a negative measure. 

However these are almost inverted measures that would almost mean the same if presented correctly... For example, we only have 2% MTBF, or we have a impressive 98% reliability!

I would definitely select tha latter to present to my customers.

Thank you again for your contribution to the great world of reliability.  :)</description>
		<content:encoded><![CDATA[<p>Hi Fred,</p>
<p>Thank you very much for the like on my post : <a href="http://bjarniis.wordpress.com/2012/01/08/logic-will-get-you-from-a-to-b-imagination-will-take-you-everywhere-albert-einstein/" rel="nofollow">http://bjarniis.wordpress.com/2012/01/08/logic-will-get-you-from-a-to-b-imagination-will-take-you-everywhere-albert-einstein/</a> </p>
<p>I would like to say I like that you would like to focus on positives rather than negatives. Uptime (reliability) is positive MTBF is a negative measure. </p>
<p>However these are almost inverted measures that would almost mean the same if presented correctly&#8230; For example, we only have 2% MTBF, or we have a impressive 98% reliability!</p>
<p>I would definitely select tha latter to present to my customers.</p>
<p>Thank you again for your contribution to the great world of reliability.  <img src='http://nomtbf.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
</channel>
</rss>

