简介一份MTBF计算书示例源自常州智电电子有限公司实际项目面向可靠性工程师、电子硬件设计及质量管理岗位系统展示了平均故障间隔时间MTBF的完整测算流程。资源为单个PDF文档体积仅187KB便于在线浏览或下载打印。文档以金属膜电阻器为主要对象详细列出RN1/2WS、RN1/4WS、RSS2W等多款电阻的型号、数量、基本失效率、环境系数、质量系数与应力系数并运用公式λpλbπEπCVπQ逐项计算工作失效率。通过具体元件位号如R1、R10、R22等展开说明涵盖25℃环境温度、GF1环境等级等典型条件帮助读者理解如何从元器件应力数据推导整机可靠性指标。全文共34页表格结构规范便于对照同类电路开展MTBF预估。已有1646人学习下载适合可靠性测试、产品认证及电子设计人员参考使用。1. MTBF计算书是什么一份让客户能追溯的可靠性档案MTBF计算书说穿了就是给产品可靠性算一笔透明账。很多硬件设备铭牌上印着「MTBF 10万小时」客户来审厂要看原始计算过程时工程师却交不出一份完整底稿——BOM没按器件分类、失效率数据说不出处、环境修正系数拍脑袋填当场翻车。MTBF计算书要做的就是把失效率数据、计算模型、修正因子的每一项都落成可追溯的记录让审查方可以顺着Excel底表一路查回去。它服务的人群很明确硬件、可靠性和质量岗位以及需要用可靠性指标做投标或验收的工程师。常见做法是先用可靠性预计手册做元器件计数法估算再用现场或试验数据做统计验证两条腿走路。这篇文章就按「模型怎么立 → 具体怎么算 → 文档怎么写 → 坑在哪」完整拆一遍。2. 失效率模型与修正因子为什么不能拿BOM直接除一除新手拿到BOM后常做的一件事是把每个器件的MTBF加起来或者求个平均然后说这就是系统MTBF。这个做法在可靠性数学上站不住。MTBF是失效率的倒数而系统失效率是按可靠性模型合并出来的不是器件的平均。这一章先把数据来源、可靠性模型、修正因子三件事立住后面算起来才不会翻车。2.1 手册预估与实测统计两条数据路线的取舍常见的MTBF计算路线分两类。一类是手册预估法按可靠性预计手册查每个器件的失效率再乘上环境、质量、温度修正因子最后合并得到系统失效率。另一类是实测统计法对已经量产使用的产品统计累计工作台时、故障次数用统计分布算出MTBF的区间估计。前者在图纸还没齐、没有现场数据时用后者在批量交付后或用试验数据做验证时用。我一般建议投标阶段先用手册法把底数摸出来等有半年以上现场数据后再用实测法校正一次两份结果都留在计算书里。需要说清楚的是两条路线算出来的MTBF数字往往不同甚至差一倍以上。手册法偏保守因为它建立在「器件在额定应力下工作」的假设上实测法更接近真实使用但受样本量、维修策略、统计口径影响大。计算书里要写明用的是哪种方法、为什么用这种而不是把两种结果混在一起挑好听的报。2.2 串联可靠性模型系统失效率是加法不是除法可靠性数学的基础假设是一个由n个器件串联的系统任何一个器件失效都会导致整个系统失效且各器件失效相互独立。在这个假设下系统失效率是各器件失效率之和。注意是失效率相加不是把MTBF相加或平均。很多人刚接触时会觉得「两个MTBF 5万小时的器件加起来系统应该更可靠」实际正好相反。举个例子。器件A的MTBF是10,000小时失效率1×10⁻⁴/h器件B的MTBF是100,000小时失效率1×10⁻⁵/h。串联后的系统失效率是1.1×10⁻⁴/h折算MTBF约9,091小时。系统MTBF比两个器件里较低的那个还要低一点。想提高系统MTBF就要优先处理失效率最大的那个器件这是后面做帕累托分析的基础。如果系统里有冗余比如双电源并联就不能简单按串联相加了。工程上会在计算书里单独建模任务时间t内并联结构的可靠度是1减去两个单元都失效的概率等效失效率与t有关不是一个固定值。做法是在可靠性框图里区分「串联单元」和「冗余单元」分别计算后再合并而不是把冗余单元直接套进串联合并里。2.3 环境、质量、温度三张因子表藏坑最多的地方元器件失效率的标准表达式是λ_i λ_b × π_Q × π_E × π_T。每一项的含义和使用时的常见误区我直接列在下面。λ_b是基本失效率手册按器件类型给出单位通常用Fit1 Fit 10⁻⁹/h表示每十亿小时失效数。π_Q是质量因子同样是电阻军品、工业级、商业级差别可以到好几倍。π_E是环境因子实验室、固定地面、车载、机载环境下差别很大环境越严酷因子越高。π_T是温度因子依赖器件结温和环境温度是三个因子中对结果影响最大的。下面是三个因子的量级参考表。注意这些数字只用于建立量级直觉具体取值必须查选定手册的对应章节不同手册对环境的分类方式和数值范围都不一样。因子类型典型取值与说明π_E 环境因子地面良好约1.0地面固定约1.22地面移动约38机载封闭环境更高π_Q 质量因子军品级约0.51工业级约13商业级约38π_T 温度因子温度每升高约10°C失效率近似翻倍Ea0.7eV时从25°C升到55°C可达10倍量级注意因子取值不要拍脑袋。评审方一般不会要求你记得每个数值但会抽查你取的π_Q、π_E、π_T能不能在手册对应表里查到所以取值路径要留在底稿里能指到具体页。3. MTBF计算示例从BOM底表到置信下限的完整流程这一章用一个虚构的某工业控制器主板把计算流程完整跑一遍。BOM简化到八类器件目标是让你能照着同样的步骤把手里的真实BOM算成MTBF。过程分两段先手工算再写脚本批量算最后处理实测数据的置信区间。3.1 元器件计数法手工算一遍建立直觉手工计算的步骤很简单但每一步都有讲究从BOM里按位号列出所有器件相同类型合并成一行记下数量。按选定手册查每类器件的基本失效率λ_b单位统一成Fit。根据器件质量等级确定π_Q。根据产品使用环境确定π_E。根据器件工作温度确定π_T注意同板不同区域分开取。每行算λ_i λ_b × π_Q × π_E × π_T再乘数量得到本行小计。所有小计求和得到系统失效率取倒数得到MTBF点估计。器件类别数量λ_b(Fit)π_Qπ_Eπ_T单体λ(Fit)小计(Fit)贴片电阻0805800.51.01.02.01.080陶瓷贴片电容X7R601.01.01.02.02.0120电解电容1030.02.01.03.0180.01800MCU180.02.01.02.0320.0320晶振120.02.01.02.080.080电源模块1250.02.01.02.01000.01000连接器20.51.01.01.00.51LED43.01.01.01.54.518提示上表所有λ_b和因子值仅为演示不是某份真实手册的正式数据。实际计算时每一行都必须能指向你所用手册的具体章节否则这份底表不具备可审查性。这张表加总后系统失效率是3,419 Fit即3.419×10⁻⁶/hMTBF点估计约292,000小时。注意电解电容一行就贡献了1,800 Fit占了一半以上。这说明影响系统MTBF的主要矛盾往往集中在少数几类器件上。3.2 用Python把底表批量算出MTBF手工算一次可以建立直觉但评审时要改因子、换器件、对比方案手工重算太慢了。我一般会把底表转成脚本一行一个器件类别直接跑出系统失效率和MTBF。from dataclasses import dataclass dataclass class Part: name: str # 器件类别用于输出和排查 qty: int # 数量来自BOM位号统计 lb: float # 基本失效率单位 Fit (10^-9/h) pi_q: float # 质量因子 pi_e: float # 环境因子 pi_t: float # 温度因子 bom [ Part(贴片电阻0805, 80, 0.5, 1.0, 1.0, 2.0), Part(陶瓷贴片电容X7R, 60, 1.0, 1.0, 1.0, 2.0), Part(电解电容, 10, 30.0, 2.0, 1.0, 3.0), Part(MCU, 1, 80.0, 2.0, 1.0, 2.0), Part(晶振, 1, 20.0, 2.0, 1.0, 2.0), Part(电源模块, 1, 250.0, 2.0, 1.0, 2.0), Part(连接器, 2, 0.5, 1.0, 1.0, 1.0), Part(LED, 4, 3.0, 1.0, 1.0, 1.5), ] total_lambda 0.0 # 系统总失效率单位 Fit for p in bom: one p.lb * p.pi_q * p.pi_e * p.pi_t # 单个器件失效率(Fit) subtotal one * p.qty # 本行小计(Fit) total_lambda subtotal print(f{p.name:16s} 数量{p.qty:3d} 单体{one:8.1f}Fit 小计{subtotal:8.1f}Fit) system_lambda_per_h total_lambda * 1e-9 # Fit 转成 1/h mtbf 1 / system_lambda_per_h # 单位小时 print(f\n系统失效率: {total_lambda:.1f} Fit {system_lambda_per_h:.3e}/h) print(fMTBF点估计: {mtbf:,.0f} 小时 {mtbf/8760:,.1f} 年)这段脚本保持了和Excel底表一致的结构评审时改一个因子重跑一遍就能出结果。Fit转成1/h的换算放在最后避免中途出现很小的浮点数。如果要加新器件直接往bom列表里加一行无需改动后面逻辑。算完之后顺手做一次贡献率排序对后续设计改进很有用。加一小段就能输出每类器件在总失效率里的占比rows [] for p in bom: one p.lb * p.pi_q * p.pi_e * p.pi_t rows.append((p.name, one * p.qty)) rows.sort(keylambda x: x[1], reverseTrue) for name, fit in rows: print(f{name:16s} {fit:8.1f}Fit 占比{fit/total_lambda*100:4.1f}%)这段先把各行小计算出来存进列表按小计降序排序再除以总失效率得到占比。输出结果通常很扎心排名前三的器件类别经常贡献了70%以上的失效率这就是后面做可靠性改进的靶子。3.3 实测数据与置信下限用卡方分布算数手册预估法给的是点估计而真正用来验收、签合同的数字工程上普遍要求给置信下限。当产品已经有现场运行数据或做了可靠性验证试验时用卡方分布算区间是标准做法。点估计公式是θ̂ T / r其中T是累计设备工作台时r是故障次数。置信下限公式为θ_L 2T / χ²(2r2, 1−α)α0.1时对应90%置信下限。这个公式的来源是故障过程服从泊松过程时故障次数的卡方统计量可靠性鉴定试验标准里也用它。Python里可以这样算from scipy.stats import chi2 def mtbf_lower_bound(T: float, r: int, alpha: float 0.1) - float: 累计工作T台时、故障r次时置信度(1-alpha)的MTBF置信下限 df 2 * r 2 quantile chi2.ppf(1 - alpha, df) # 90%置信下限取0.9分位 return 2 * T / quantile T, r 200_000, 2 point T / r lower mtbf_lower_bound(T, r, 0.1) print(f点估计: {point:.0f} h) print(f90%置信下限: {lower:.0f} h)这段代码依赖scipy库用pip install scipy安装即可如果不能装包工程上查卡方分布表也能得到同样的分位数Excel里用CHISQ.INV.RT(0.1, 2*r2)也能算。特别要提无故障情形。现场一台都没坏时r0点估计是无穷大但没人会接受这个结论。此时df290%置信度下χ²分位数为4.605θ_L 2T / 4.605 ≈ 0.434T。也就是说跑了20万台时没坏最多只能保守地报约8.68万小时的置信下限。这个0.434倍关系非常实用评审时经常被问到。提示对外承诺用置信下限内部做方案对比可以用点估计但两者要在文档里分开标注不要混写。4. 计算书写成什么样才能过评审文档骨架与数据底表MTBF计算书不是一张算完的Excel就能交差的。客户和评审方要看的是完整的逻辑链这个产品在什么条件下使用、模型怎么建、数据从哪来、结论怎么得出。我一般按下面的结构组织评审方也熟悉这套顺序。4.1 计算书结构产品定义、任务剖面与可靠性模型一份能过评审的计算书建议至少包含六块内容产品概述与范围产品型号、功能、适用标准、本次计算的BOM版本基线。任务剖面工作环境温度、湿度、振动水平、通电占空比、目标寿命年限。可靠性模型可靠性框图文字描述串联/冗余关系、关键假设独立失效、串联模型。元器件数据底表作为附件或独立Excel正文引用汇总结果。计算过程给出λsys和MTBF点估计的完整推导。结论点估计、置信下限、数据来源声明、遗留风险。任务剖面是最容易被忽略的。同一块板在25°C机房和在70°C机箱里MTBF差好几倍所以必须写清楚这份计算书对应什么使用场景。如果产品有多个应用环境就分别算一张底表不要试图用一个代表值覆盖所有场景。可靠性模型部分画不了复杂框图时用一张表就能说清楚单元名称、工作方式串联/冷备/并联、失效模式、失效率值。纯串联系统只要写一句「各单元串联任一失效即整机失效」有冗余时就得单独给每个冗余支路建模不能把两个并联单元按一个串联单元处理。4.2 元器件数据底表每一行都要写得出处底表是整个计算书的证据核心。字段设计直接决定评审方愿不愿意放你过建议至少包含下表这些列。字段说明是否必填位号BOM里的唯一标识如R12、C34必须器件名称规范名称不写俗称必须型号规格具体选型关系到质量等级判定必须数量来自BOM必须基本失效率λ_b单位Fit注明手册章节必须π_Q/π_E/π_T三个修正因子必须单体失效率λ_iλ_b × π_Q × π_E × π_T必须小计λ_i × 数量必须数据来源手册名称、版本、页码或供应商报告必须来源列是最容易糊弄的。不规范的写法是「手册」规范写法是「GJB/Z 299C某页表某」。供应商给的IC失效率数据要附上报告标题与日期如果来自内部失效分析要标注样本量和统计区间。客户随便抽查三行哪一行都答得出来这份底表才算过关。还有一个常见问题是器件的选型变化。同一个位号把型号从A换成B即使外观和引脚兼容λ_b和π_Q也可能完全不同底表必须跟着重算。这也是为什么要做版本管理。4.3 版本管理与变更重算计算书是台账不是作文计算书是活文档。版本记录至少包含版本号、日期、依据的BOM版本、主要变更内容、计算人、审核人。变更后旧版本不删除和底稿一起归档。常见触发重算的场景有BOM换料、工作温度规格调整、环境等级变化、布局改版导致散热改善、客户要求切换计算标准。我自己的习惯是底表用Excel加CSV双备份。Excel用于评审展示CSV用于让Python脚本直接读取重新计算脚本和底表放同一个版本目录。这样下次评审时能完整还原「上次到底怎么算出来的」不会出现换了台电脑就算不回来的尴尬。提示把底稿放到公司服务器或版本库里不要停在个人电脑桌面。变更审计时拿不出历史版本比算错数字还要难看。5. MTBF计算避坑指南评审被打回的5个真实原因下面五条是我在评审和送审现场见过最多的翻车原因。每条按「现象、原因、解决」写遇到同款问题可以直接照着排查。5.1 只看结论不看来源底表没有出处列现象底表里每一行只有λ_i的值没有来源列。评审问第一行数据的出处工程师答不上来会议当场冷场。原因计算时从别人那儿拷贝了表格或者手工查完没留痕迹以为自己查过就够了。解决把来源列设为底表必填项填到「手册名版本页码表号」粒度。如果公司内部有公共可靠性数据库就填数据库名称和条目ID注明查阅日期。自查标准很简单随机挑三行能当场说出出处才算合格。5.2 温度因子一刀切MTBF低到没法交现象整张底表统一取π_T4或更高算出来的系统MTBF只有几百小时和同类型产品差一个数量级设计团队根本不敢信。原因把「最坏情况」当成了默认情况。温度因子随温度指数上升所有器件都按同一个最高热点温度取值结果被少数热敏感器件带偏。解决按区域给温度。电源附近、CPU附近的器件用热点温度远离热源的电阻电容用环境温度每个区域在底表里加一列「温度取值依据」。拿不准时取档位而不是精确值但要在备注里写清档位定义。5.3 混用两套手册数据数值自洽却经不起追问现象一份计算书里电阻用的是A手册的λ_bIC用的是B手册的λ_b环境因子又从C手册抄单独看每一项都对合在一起数值却两头不靠。原因不同手册对「基本失效率」的定义不一样对环境的分类粒度也不一样混用后数值没有可比性。解决全篇只认一本手册。要换就整张底表重算并在版本记录里写明「从某手册切到另一手册」。混合使用的前提是能证明两本手册的数据定义一致工程上一般不建议评审方也最反感这种拼凑式数据。5.4 半导体器件直接抄旧项目IC失效率不是常数现象同一颗MCU在旧项目计算书里用的是某个失效率值新项目换了封装和工艺仍直接抄旧数值连备注都没改。原因IC的失效率与复杂度、工艺、封装、结温、质量等级强相关不是一个通用常数。抄来的值既不能体现工艺改进也不能体现应力差异。解决按手册的IC类目重新判定复杂度等级和封装因子或优先采用供应商提供的可靠性报告。如果没有供应商数据就明确标注「按手册对应类目取」并把决定依据写进备注。5.5 把点估计当承诺值对外口径翻车现象投标文件直接写「MTBF 100,000小时」而底表只算了点估计没有区间口径。最后验收时拿不出对应的验证记录引发交付争议。原因点估计是统计意义上的平均值不等于保证值。算出来10万小时不代表每台都能跑10万小时合同纠纷往往出在这里。解决对外口径一律用置信下限并写明置信度和统计条件。比如「90%置信下限50,000小时」比「MTBF 100,000小时」更诚实也更能扛住审计。内部如需用点估计做设计对比留在底稿里可以但不进合同。6. 把计算书变成改进工具帕累托分析与验证试验反推6.1 先算贡献率三个器件决定系统MTBF算完MTBF先别急着写结论先把每类器件的失效率小计按从大到小排序。以第3章示例底表为例电解电容1,800 Fit排第一电源模块1,000 Fit第二MCU 320 Fit第三这三项加起来占系统总失效率的91%。系统MTBF想翻倍盯着这三项改进比把剩下五类器件全部换一遍更快。这个动作让计算书从「交付物」变成了「分析工具」——它直接告诉设计团队换一家更可靠的电源模块、把电解电容换成高分子固态电容、给MCU降低工作温度每个动作能换回来多少MTBF增量。评审时被问「为什么MTBF只有这么多」直接指top项比解释一堆模型假设有效得多。6.2 用置信下限反推无故障试验时间如果计算书里承诺了某个置信下限可以反向算出为了验证它需要跑多少台时。无故障条件下θ_L 2T / 4.605所以T ≈ 2.30 × θ_L。举个例子目标90%置信下限50,000小时需要的累计试验台时约115,000台时10台样机要跑约11,500小时按全天运行折算约480天。样机翻倍到20台时间就缩到240天。目标置信下限(h)需要的无故障累计台时(h)10,000约23,00020,000约46,00050,000约115,000表中按90%置信度、无故障条件估算。如果试验过程中出现故障所需时间还要按第3.3节的卡方公式重新计算。这个反推表让我在做验证试验排期时不再拍脑袋。以前我总习惯把MTBF算出来就收工后来发现评审最关心的是「你打算怎么证明这个数」。现在我的习惯是每版计算书都顺手附一张试验时间反推表把验证投入摊在明面上方案落地性反而更强。希望帮到你。本文还有配套的精品资源点击获取
简介一份MTBF计算书示例源自常州智电电子有限公司实际项目面向可靠性工程师、电子硬件设计及质量管理岗位系统展示了平均故障间隔时间MTBF的完整测算流程。资源为单个PDF文档体积仅187KB便于在线浏览或下载打印。文档以金属膜电阻器为主要对象详细列出RN1/2WS、RN1/4WS、RSS2W等多款电阻的型号、数量、基本失效率、环境系数、质量系数与应力系数并运用公式λpλbπEπCVπQ逐项计算工作失效率。通过具体元件位号如R1、R10、R22等展开说明涵盖25℃环境温度、GF1环境等级等典型条件帮助读者理解如何从元器件应力数据推导整机可靠性指标。全文共34页表格结构规范便于对照同类电路开展MTBF预估。已有1646人学习下载适合可靠性测试、产品认证及电子设计人员参考使用。1. MTBF计算书是什么一份让客户能追溯的可靠性档案MTBF计算书说穿了就是给产品可靠性算一笔透明账。很多硬件设备铭牌上印着「MTBF 10万小时」客户来审厂要看原始计算过程时工程师却交不出一份完整底稿——BOM没按器件分类、失效率数据说不出处、环境修正系数拍脑袋填当场翻车。MTBF计算书要做的就是把失效率数据、计算模型、修正因子的每一项都落成可追溯的记录让审查方可以顺着Excel底表一路查回去。它服务的人群很明确硬件、可靠性和质量岗位以及需要用可靠性指标做投标或验收的工程师。常见做法是先用可靠性预计手册做元器件计数法估算再用现场或试验数据做统计验证两条腿走路。这篇文章就按「模型怎么立 → 具体怎么算 → 文档怎么写 → 坑在哪」完整拆一遍。2. 失效率模型与修正因子为什么不能拿BOM直接除一除新手拿到BOM后常做的一件事是把每个器件的MTBF加起来或者求个平均然后说这就是系统MTBF。这个做法在可靠性数学上站不住。MTBF是失效率的倒数而系统失效率是按可靠性模型合并出来的不是器件的平均。这一章先把数据来源、可靠性模型、修正因子三件事立住后面算起来才不会翻车。2.1 手册预估与实测统计两条数据路线的取舍常见的MTBF计算路线分两类。一类是手册预估法按可靠性预计手册查每个器件的失效率再乘上环境、质量、温度修正因子最后合并得到系统失效率。另一类是实测统计法对已经量产使用的产品统计累计工作台时、故障次数用统计分布算出MTBF的区间估计。前者在图纸还没齐、没有现场数据时用后者在批量交付后或用试验数据做验证时用。我一般建议投标阶段先用手册法把底数摸出来等有半年以上现场数据后再用实测法校正一次两份结果都留在计算书里。需要说清楚的是两条路线算出来的MTBF数字往往不同甚至差一倍以上。手册法偏保守因为它建立在「器件在额定应力下工作」的假设上实测法更接近真实使用但受样本量、维修策略、统计口径影响大。计算书里要写明用的是哪种方法、为什么用这种而不是把两种结果混在一起挑好听的报。2.2 串联可靠性模型系统失效率是加法不是除法可靠性数学的基础假设是一个由n个器件串联的系统任何一个器件失效都会导致整个系统失效且各器件失效相互独立。在这个假设下系统失效率是各器件失效率之和。注意是失效率相加不是把MTBF相加或平均。很多人刚接触时会觉得「两个MTBF 5万小时的器件加起来系统应该更可靠」实际正好相反。举个例子。器件A的MTBF是10,000小时失效率1×10⁻⁴/h器件B的MTBF是100,000小时失效率1×10⁻⁵/h。串联后的系统失效率是1.1×10⁻⁴/h折算MTBF约9,091小时。系统MTBF比两个器件里较低的那个还要低一点。想提高系统MTBF就要优先处理失效率最大的那个器件这是后面做帕累托分析的基础。如果系统里有冗余比如双电源并联就不能简单按串联相加了。工程上会在计算书里单独建模任务时间t内并联结构的可靠度是1减去两个单元都失效的概率等效失效率与t有关不是一个固定值。做法是在可靠性框图里区分「串联单元」和「冗余单元」分别计算后再合并而不是把冗余单元直接套进串联合并里。2.3 环境、质量、温度三张因子表藏坑最多的地方元器件失效率的标准表达式是λ_i λ_b × π_Q × π_E × π_T。每一项的含义和使用时的常见误区我直接列在下面。λ_b是基本失效率手册按器件类型给出单位通常用Fit1 Fit 10⁻⁹/h表示每十亿小时失效数。π_Q是质量因子同样是电阻军品、工业级、商业级差别可以到好几倍。π_E是环境因子实验室、固定地面、车载、机载环境下差别很大环境越严酷因子越高。π_T是温度因子依赖器件结温和环境温度是三个因子中对结果影响最大的。下面是三个因子的量级参考表。注意这些数字只用于建立量级直觉具体取值必须查选定手册的对应章节不同手册对环境的分类方式和数值范围都不一样。因子类型典型取值与说明π_E 环境因子地面良好约1.0地面固定约1.22地面移动约38机载封闭环境更高π_Q 质量因子军品级约0.51工业级约13商业级约38π_T 温度因子温度每升高约10°C失效率近似翻倍Ea0.7eV时从25°C升到55°C可达10倍量级注意因子取值不要拍脑袋。评审方一般不会要求你记得每个数值但会抽查你取的π_Q、π_E、π_T能不能在手册对应表里查到所以取值路径要留在底稿里能指到具体页。3. MTBF计算示例从BOM底表到置信下限的完整流程这一章用一个虚构的某工业控制器主板把计算流程完整跑一遍。BOM简化到八类器件目标是让你能照着同样的步骤把手里的真实BOM算成MTBF。过程分两段先手工算再写脚本批量算最后处理实测数据的置信区间。3.1 元器件计数法手工算一遍建立直觉手工计算的步骤很简单但每一步都有讲究从BOM里按位号列出所有器件相同类型合并成一行记下数量。按选定手册查每类器件的基本失效率λ_b单位统一成Fit。根据器件质量等级确定π_Q。根据产品使用环境确定π_E。根据器件工作温度确定π_T注意同板不同区域分开取。每行算λ_i λ_b × π_Q × π_E × π_T再乘数量得到本行小计。所有小计求和得到系统失效率取倒数得到MTBF点估计。器件类别数量λ_b(Fit)π_Qπ_Eπ_T单体λ(Fit)小计(Fit)贴片电阻0805800.51.01.02.01.080陶瓷贴片电容X7R601.01.01.02.02.0120电解电容1030.02.01.03.0180.01800MCU180.02.01.02.0320.0320晶振120.02.01.02.080.080电源模块1250.02.01.02.01000.01000连接器20.51.01.01.00.51LED43.01.01.01.54.518提示上表所有λ_b和因子值仅为演示不是某份真实手册的正式数据。实际计算时每一行都必须能指向你所用手册的具体章节否则这份底表不具备可审查性。这张表加总后系统失效率是3,419 Fit即3.419×10⁻⁶/hMTBF点估计约292,000小时。注意电解电容一行就贡献了1,800 Fit占了一半以上。这说明影响系统MTBF的主要矛盾往往集中在少数几类器件上。3.2 用Python把底表批量算出MTBF手工算一次可以建立直觉但评审时要改因子、换器件、对比方案手工重算太慢了。我一般会把底表转成脚本一行一个器件类别直接跑出系统失效率和MTBF。from dataclasses import dataclass dataclass class Part: name: str # 器件类别用于输出和排查 qty: int # 数量来自BOM位号统计 lb: float # 基本失效率单位 Fit (10^-9/h) pi_q: float # 质量因子 pi_e: float # 环境因子 pi_t: float # 温度因子 bom [ Part(贴片电阻0805, 80, 0.5, 1.0, 1.0, 2.0), Part(陶瓷贴片电容X7R, 60, 1.0, 1.0, 1.0, 2.0), Part(电解电容, 10, 30.0, 2.0, 1.0, 3.0), Part(MCU, 1, 80.0, 2.0, 1.0, 2.0), Part(晶振, 1, 20.0, 2.0, 1.0, 2.0), Part(电源模块, 1, 250.0, 2.0, 1.0, 2.0), Part(连接器, 2, 0.5, 1.0, 1.0, 1.0), Part(LED, 4, 3.0, 1.0, 1.0, 1.5), ] total_lambda 0.0 # 系统总失效率单位 Fit for p in bom: one p.lb * p.pi_q * p.pi_e * p.pi_t # 单个器件失效率(Fit) subtotal one * p.qty # 本行小计(Fit) total_lambda subtotal print(f{p.name:16s} 数量{p.qty:3d} 单体{one:8.1f}Fit 小计{subtotal:8.1f}Fit) system_lambda_per_h total_lambda * 1e-9 # Fit 转成 1/h mtbf 1 / system_lambda_per_h # 单位小时 print(f\n系统失效率: {total_lambda:.1f} Fit {system_lambda_per_h:.3e}/h) print(fMTBF点估计: {mtbf:,.0f} 小时 {mtbf/8760:,.1f} 年)这段脚本保持了和Excel底表一致的结构评审时改一个因子重跑一遍就能出结果。Fit转成1/h的换算放在最后避免中途出现很小的浮点数。如果要加新器件直接往bom列表里加一行无需改动后面逻辑。算完之后顺手做一次贡献率排序对后续设计改进很有用。加一小段就能输出每类器件在总失效率里的占比rows [] for p in bom: one p.lb * p.pi_q * p.pi_e * p.pi_t rows.append((p.name, one * p.qty)) rows.sort(keylambda x: x[1], reverseTrue) for name, fit in rows: print(f{name:16s} {fit:8.1f}Fit 占比{fit/total_lambda*100:4.1f}%)这段先把各行小计算出来存进列表按小计降序排序再除以总失效率得到占比。输出结果通常很扎心排名前三的器件类别经常贡献了70%以上的失效率这就是后面做可靠性改进的靶子。3.3 实测数据与置信下限用卡方分布算数手册预估法给的是点估计而真正用来验收、签合同的数字工程上普遍要求给置信下限。当产品已经有现场运行数据或做了可靠性验证试验时用卡方分布算区间是标准做法。点估计公式是θ̂ T / r其中T是累计设备工作台时r是故障次数。置信下限公式为θ_L 2T / χ²(2r2, 1−α)α0.1时对应90%置信下限。这个公式的来源是故障过程服从泊松过程时故障次数的卡方统计量可靠性鉴定试验标准里也用它。Python里可以这样算from scipy.stats import chi2 def mtbf_lower_bound(T: float, r: int, alpha: float 0.1) - float: 累计工作T台时、故障r次时置信度(1-alpha)的MTBF置信下限 df 2 * r 2 quantile chi2.ppf(1 - alpha, df) # 90%置信下限取0.9分位 return 2 * T / quantile T, r 200_000, 2 point T / r lower mtbf_lower_bound(T, r, 0.1) print(f点估计: {point:.0f} h) print(f90%置信下限: {lower:.0f} h)这段代码依赖scipy库用pip install scipy安装即可如果不能装包工程上查卡方分布表也能得到同样的分位数Excel里用CHISQ.INV.RT(0.1, 2*r2)也能算。特别要提无故障情形。现场一台都没坏时r0点估计是无穷大但没人会接受这个结论。此时df290%置信度下χ²分位数为4.605θ_L 2T / 4.605 ≈ 0.434T。也就是说跑了20万台时没坏最多只能保守地报约8.68万小时的置信下限。这个0.434倍关系非常实用评审时经常被问到。提示对外承诺用置信下限内部做方案对比可以用点估计但两者要在文档里分开标注不要混写。4. 计算书写成什么样才能过评审文档骨架与数据底表MTBF计算书不是一张算完的Excel就能交差的。客户和评审方要看的是完整的逻辑链这个产品在什么条件下使用、模型怎么建、数据从哪来、结论怎么得出。我一般按下面的结构组织评审方也熟悉这套顺序。4.1 计算书结构产品定义、任务剖面与可靠性模型一份能过评审的计算书建议至少包含六块内容产品概述与范围产品型号、功能、适用标准、本次计算的BOM版本基线。任务剖面工作环境温度、湿度、振动水平、通电占空比、目标寿命年限。可靠性模型可靠性框图文字描述串联/冗余关系、关键假设独立失效、串联模型。元器件数据底表作为附件或独立Excel正文引用汇总结果。计算过程给出λsys和MTBF点估计的完整推导。结论点估计、置信下限、数据来源声明、遗留风险。任务剖面是最容易被忽略的。同一块板在25°C机房和在70°C机箱里MTBF差好几倍所以必须写清楚这份计算书对应什么使用场景。如果产品有多个应用环境就分别算一张底表不要试图用一个代表值覆盖所有场景。可靠性模型部分画不了复杂框图时用一张表就能说清楚单元名称、工作方式串联/冷备/并联、失效模式、失效率值。纯串联系统只要写一句「各单元串联任一失效即整机失效」有冗余时就得单独给每个冗余支路建模不能把两个并联单元按一个串联单元处理。4.2 元器件数据底表每一行都要写得出处底表是整个计算书的证据核心。字段设计直接决定评审方愿不愿意放你过建议至少包含下表这些列。字段说明是否必填位号BOM里的唯一标识如R12、C34必须器件名称规范名称不写俗称必须型号规格具体选型关系到质量等级判定必须数量来自BOM必须基本失效率λ_b单位Fit注明手册章节必须π_Q/π_E/π_T三个修正因子必须单体失效率λ_iλ_b × π_Q × π_E × π_T必须小计λ_i × 数量必须数据来源手册名称、版本、页码或供应商报告必须来源列是最容易糊弄的。不规范的写法是「手册」规范写法是「GJB/Z 299C某页表某」。供应商给的IC失效率数据要附上报告标题与日期如果来自内部失效分析要标注样本量和统计区间。客户随便抽查三行哪一行都答得出来这份底表才算过关。还有一个常见问题是器件的选型变化。同一个位号把型号从A换成B即使外观和引脚兼容λ_b和π_Q也可能完全不同底表必须跟着重算。这也是为什么要做版本管理。4.3 版本管理与变更重算计算书是台账不是作文计算书是活文档。版本记录至少包含版本号、日期、依据的BOM版本、主要变更内容、计算人、审核人。变更后旧版本不删除和底稿一起归档。常见触发重算的场景有BOM换料、工作温度规格调整、环境等级变化、布局改版导致散热改善、客户要求切换计算标准。我自己的习惯是底表用Excel加CSV双备份。Excel用于评审展示CSV用于让Python脚本直接读取重新计算脚本和底表放同一个版本目录。这样下次评审时能完整还原「上次到底怎么算出来的」不会出现换了台电脑就算不回来的尴尬。提示把底稿放到公司服务器或版本库里不要停在个人电脑桌面。变更审计时拿不出历史版本比算错数字还要难看。5. MTBF计算避坑指南评审被打回的5个真实原因下面五条是我在评审和送审现场见过最多的翻车原因。每条按「现象、原因、解决」写遇到同款问题可以直接照着排查。5.1 只看结论不看来源底表没有出处列现象底表里每一行只有λ_i的值没有来源列。评审问第一行数据的出处工程师答不上来会议当场冷场。原因计算时从别人那儿拷贝了表格或者手工查完没留痕迹以为自己查过就够了。解决把来源列设为底表必填项填到「手册名版本页码表号」粒度。如果公司内部有公共可靠性数据库就填数据库名称和条目ID注明查阅日期。自查标准很简单随机挑三行能当场说出出处才算合格。5.2 温度因子一刀切MTBF低到没法交现象整张底表统一取π_T4或更高算出来的系统MTBF只有几百小时和同类型产品差一个数量级设计团队根本不敢信。原因把「最坏情况」当成了默认情况。温度因子随温度指数上升所有器件都按同一个最高热点温度取值结果被少数热敏感器件带偏。解决按区域给温度。电源附近、CPU附近的器件用热点温度远离热源的电阻电容用环境温度每个区域在底表里加一列「温度取值依据」。拿不准时取档位而不是精确值但要在备注里写清档位定义。5.3 混用两套手册数据数值自洽却经不起追问现象一份计算书里电阻用的是A手册的λ_bIC用的是B手册的λ_b环境因子又从C手册抄单独看每一项都对合在一起数值却两头不靠。原因不同手册对「基本失效率」的定义不一样对环境的分类粒度也不一样混用后数值没有可比性。解决全篇只认一本手册。要换就整张底表重算并在版本记录里写明「从某手册切到另一手册」。混合使用的前提是能证明两本手册的数据定义一致工程上一般不建议评审方也最反感这种拼凑式数据。5.4 半导体器件直接抄旧项目IC失效率不是常数现象同一颗MCU在旧项目计算书里用的是某个失效率值新项目换了封装和工艺仍直接抄旧数值连备注都没改。原因IC的失效率与复杂度、工艺、封装、结温、质量等级强相关不是一个通用常数。抄来的值既不能体现工艺改进也不能体现应力差异。解决按手册的IC类目重新判定复杂度等级和封装因子或优先采用供应商提供的可靠性报告。如果没有供应商数据就明确标注「按手册对应类目取」并把决定依据写进备注。5.5 把点估计当承诺值对外口径翻车现象投标文件直接写「MTBF 100,000小时」而底表只算了点估计没有区间口径。最后验收时拿不出对应的验证记录引发交付争议。原因点估计是统计意义上的平均值不等于保证值。算出来10万小时不代表每台都能跑10万小时合同纠纷往往出在这里。解决对外口径一律用置信下限并写明置信度和统计条件。比如「90%置信下限50,000小时」比「MTBF 100,000小时」更诚实也更能扛住审计。内部如需用点估计做设计对比留在底稿里可以但不进合同。6. 把计算书变成改进工具帕累托分析与验证试验反推6.1 先算贡献率三个器件决定系统MTBF算完MTBF先别急着写结论先把每类器件的失效率小计按从大到小排序。以第3章示例底表为例电解电容1,800 Fit排第一电源模块1,000 Fit第二MCU 320 Fit第三这三项加起来占系统总失效率的91%。系统MTBF想翻倍盯着这三项改进比把剩下五类器件全部换一遍更快。这个动作让计算书从「交付物」变成了「分析工具」——它直接告诉设计团队换一家更可靠的电源模块、把电解电容换成高分子固态电容、给MCU降低工作温度每个动作能换回来多少MTBF增量。评审时被问「为什么MTBF只有这么多」直接指top项比解释一堆模型假设有效得多。6.2 用置信下限反推无故障试验时间如果计算书里承诺了某个置信下限可以反向算出为了验证它需要跑多少台时。无故障条件下θ_L 2T / 4.605所以T ≈ 2.30 × θ_L。举个例子目标90%置信下限50,000小时需要的累计试验台时约115,000台时10台样机要跑约11,500小时按全天运行折算约480天。样机翻倍到20台时间就缩到240天。目标置信下限(h)需要的无故障累计台时(h)10,000约23,00020,000约46,00050,000约115,000表中按90%置信度、无故障条件估算。如果试验过程中出现故障所需时间还要按第3.3节的卡方公式重新计算。这个反推表让我在做验证试验排期时不再拍脑袋。以前我总习惯把MTBF算出来就收工后来发现评审最关心的是「你打算怎么证明这个数」。现在我的习惯是每版计算书都顺手附一张试验时间反推表把验证投入摊在明面上方案落地性反而更强。希望帮到你。本文还有配套的精品资源点击获取
