Subscribe to Blog via Email
© Mark Biegert and Math Encounters, 2020. Publication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Mark Biegert and Math Encounters with appropriate and specific direction to the original content.
DisclaimerAll content provided on the mathscinotes.com blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner of mathscinotes.com will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Daily Archives: 4-February-2019
erforming an MTBF prediction is to designing HW as putting a license plate on your car is to driving the car. You need the license to legally drive the car, but it adds no value to your driving experience. Similarly, every company I have worked for demands a predicted MTBF for every HW product, but it adds no value to the design process. In fact, I would argue that generating the MTBF predictions actually adds negative value to the product deployment because it generates a number that is often misused by customers to estimate spare requirements and field support costs. Since no one has told customers otherwise, they think the MTBF value accurately reflects the real failure rate of a product. In fact, MTBF predictions provide a gross estimate of the rate of random parts failure at product maturity. Continue reading