话说可靠性中5个“9”的疑惑

JUMU实名认证 发表于 2019-06-28 23:18 | 显示全部楼层 | 复制链接分享      上一主题  翻页  下一主题
    前段时间,用WQS(WindchillQuality Solutions )软件基于SR332可靠性(Reliability)预计给出了我们一个产品的MTBF预计值到客户。结果被前端告知:客户反应我们里面的一个主板达不到5个9的可靠性(Reliability)要求。当时就困惑了...什么是5个9?客户是不是说99.999%的可靠性(Reliability)呢?如果是指可靠性(Reliability),通常电子产品如果基于指数分布R=e(-λt),λ=1/MTBF,现在MTBF已知,但时间t是未知的,怎么就说达不到要求的5个9的可靠性(Reliability)呢?
    后来找到了客户的原始邮件,里面提到的是Availability(可用性),并非之前自己理解的指数分布的可靠性(Reliability)的概率值,搞清方向,问题就好办了,运用固有可用性计算公式:A=MTBF/(MTBF+MTTR)(这里A指可用性Availability);
    MTBF已知为2,000,000小时(这里数字为参考,与实际值在一个数量级),MTTR的取值定义为1小时(因为MTTR指平均修复时间,这产品按照我的实际经验,正常拆装重组到恢复运行要1个小时,这意味着即使不修坏了的主板,直接更换性维修也至少1小时,所以这里MTTR先去最小值1小时)。算出来A=2000000/(2000000+1)=0.99999950000025=99.999950000025%;
    这一看,6个9了....想想,怎么客户还说不符合呢?难道客户的MTTR时间很长,考虑了实际的现场维护可能出现的维修延迟?例如更换板卡和协调人员维修等耽误的时间等...利用反推法,假设刚好满足5个9的可用性,算出MTTR=20小时,意味着维修时间若超过20小时,则达不到5个9的要求;因为现场维护时间对于不同场景均有不同,后来有      询问客户他们的通常售后维护MTTR时间,并告知客户我们目前的MTBF为预计值且指定了SR332里面的Issue 3,Method 1, Case 1的预计算法,不同预计算法得出的值都有差异。可能由于商业或者其他原因,客户不愿透露他们的预计方法及MTTR取值参数,且也未再提我们的产品不能达到5个9的要求....
    注意:不建议直接将可靠性(Reliability)预计值直接代入计算可用性,有条件的情况下,为了更接近现场,通常使用加速测试方案卡方分布单侧置信得出的MTBF值进行计算。

    说来也巧,在解答了上面的疑问后,第二天便看到了关注的“可靠性(Reliability)知识”公众号出了一篇文章:可靠性(Reliability)几个“9”什么意思,把人搞疯了。很及时的一篇文章,里面提到了企业经常宣传的几个9的定义级别,提到了一般电信级设备要求5个9的要求。对于里面的提及的一年允许中断时间的计算方法,引用“可靠性(Reliability)知识”公众号文章里1个9和5个9各自对应的一年允许中断时间如下:
*1个9:
(1-90%)*365=36.5天;

*5个9:
(1-99.999%)*365*24*60=5.26分钟;

这里有人可能会有疑惑怎么直接算出上面的值,下面我运用可用度公式分别验证了这两个计算方法如下:
先说1个9;A=MTBF/(MTBF+MTTR);这里A=0.9,MTBF+MTTR=1年(因为描述里写了一年内允许的中断时间,假设时间长度为1年,则无故障时间+故障维修时间总和为一年,即MTBF+MTTR=1年),代入得如下等式:
0.9=(365-MTTR)/365;继而推导出MTTR=(1-0.9)*365=36.5天,吻合;
再说5个9;同样的道理,代入得出0.99999=(365-MTTR)/365,MTTR=(1-0.99999)*365*24*60=5.256分钟,吻合。


  距米网  

找到您想要的设计

工程师、学生在线交流学习平台
关注我们

手机版- 距米网 |苏公网安备32041102000587号

©2017-2025 苏ICP备18040927号-1