企业官网建设流程全解析

简介：MTBF计算书及计算示例的PDF文档，面向可靠性工程师、硬件设计人员与质量管理人员，解决如何从元器件失效率出发进行平均故障间隔时间（MTBF）评估的问题。压缩包内共1个PDF文件，约187KB，内容以常州智电电子有限公司实际案例为背景，在80VDC输入、满负载条件下，分步骤演示了金属膜电阻器的MTBF计算过程。文档详细列出了λp＝λbπEπCVπQ公式中各系数（基本失效率、环境系数、应力系数、质量系数）的取值依据，并针对RN系列、RSS系列等多种型号电阻，逐一给出数量、失效率与系数组合的查表与计算方法。该资源已吸引1646人浏览学习，适合需要参照真实模板开展产品可靠性预计或审核MTBF计算书的从业人员。通过研读这份计算书，读者可快速掌握MTBF计算中环境温度、应力比、质量等级等参数的选取逻辑，并直接迁移用于自身电路板可靠性分析工作。

1. MTBF计算书：交付的不是一个数字，而是一套解释得通的逻辑

翻开一份被退回重做的 MTBF 计算书，十有八九不是公式算错了，而是没把「故障」两个字定义清楚。我在某项目上就翻过一次车：现场统计了半年数据，点估计算出 MTBF 五万小时，评审专家只问了一句「这个数值的置信区间是多少」，整本计算书就得返工。MTBF计算书（MTBF计算示例）解决的是这样一件事：把一台设备或一套系统「平均运行多久才坏一次」这件事，用可追溯的数据、清晰的假设和可复现的公式写成一页纸。适合投标技术文件编制、验收报告撰写、维修策略设计的人，新手能照着算，熟手能拿来对齐口径。

2. 算 MTBF 之前先定两件事：统计口径和寿命模型

2.1 四种 MTBF 口径：预计值、试验值、现场值、合同值别混着用

很多人以为 MTBF 只有一个值，其实工程上至少存在四种口径，算出来的数字可能差一个数量级。第一种是预计值，设计阶段用行业标准里的元器件失效率逐项累加出来的，属于「设计承诺」，一般偏保守；第二种是试验值，在实验室里用加速寿命试验或可靠性验证试验测出来的；第三种是现场值，从用户实际运行记录里统计出来的；第四种是合同值，是采购合同里约定的验收目标，往往写成「MTBF 不低于 XX 小时」。

这四种口径混用是计算书最常见的返工原因。投标阶段拿预计值写进技术方案没问题，但到了验收阶段如果直接拿现场统计值去对合同值，两边经常会发现「对不上」。我做计算书的第一件事，就是在首页醒目标注本次采用哪种口径、服务于哪个阶段，后面所有公式和数据都按这个口径走。如果一份计算书既用了预计失效率，又混进了现场故障次数，评审专家一眼就能看出来。

还有一种隐蔽的混用：把「MTBF 预计值」当成「承诺寿命」写进合同附件。MTBF 是统计意义上的平均无故障时间，不是每台设备都能达到的保证值。在指数分布假设下，设备运行到 MTBF 时刻的可靠度只有约 36.8%，也就是说，有 63.2% 的设备在到达 MTBF 之前已经发生过故障。这个反直觉结论不写清楚，验收时必被追问。

2.2 指数分布还是威布尔分布：看故障率曲线和 β 值定模型

选定口径之后，第二步是选寿命分布模型。MTBF 并不是只能配指数分布，只是指数分布数学上最简单，工程上最常用，但它隐含一个强假设：故障率恒定，设备不随年龄变老。这个假设只在浴盆曲线的偶然失效期才成立。

如果你的数据来自早期失效期（新设备刚量产、前几百小时故障集中爆发），或者来自耗损失效期（机械磨损、密封老化、轴承疲劳），故障率并不恒定。这时候用威布尔分布更合适，它的形状参数 β 直接告诉你设备处于什么阶段：β 小于 1 是早期失效，β 等于 1 等价于指数分布，β 大于 1 是耗损失效。工程上判断模型不靠感觉，把故障间隔时间排序后做威布尔概率图拟合，拟合出的直线斜率就是 β 的估计值。

威布尔分布下 MTBF 的计算公式是 η·Γ(1+1/β)，需要查伽马函数表，比指数分布麻烦不少。但要注意一个细节：威布尔分布的平均寿命不等于「可靠度 50% 对应的寿命」，后者是中位寿命。有同行在计算书里把中位寿命直接写成 MTBF，这种错误在审查时很容易被专业评审抓住。我的习惯是：电子设备、批量运行的稳定期产品，默认指数分布；带旋转部件、密封件或明显磨损机理的设备，先做威布尔拟合再决定，不硬套。

3. 手算一份 MTBF 计算书：从现场故障记录到置信区间的完整步骤

3.1 把维修记录整理成可计算的统计表

先看一类典型的现场场景：某项目共部署了 50 台同类设备，统计周期为一年（8,760 小时），需要出计算书。手头能拿到的原始资料是维修工单，上面的字段参差不齐，但至少要有故障发生时间、修复时间、故障现象简述、更换的元器件或部件名称。第一步不是套公式，而是把这堆工单整理成可计算的事件表。

我一般先做一次数据清洗，把统计期内的事件分成两类：真故障和无效事件。无效事件包括预防性保养、计划内升级、外部断电、误操作导致的重启、软件版本升级后的主动重启。这些事件在计算书里不能计入故障次数，但要留一个备注表，写清楚删掉了什么、为什么删。整理后的汇总通常是这样一张表：

这张表就是计算书的「数据底座」。做这一步时最容易犯的错是直接拿「设备数量 × 日历时间」当累计运行时间，后面会单独讲。这里先记住：T 的单位是小时，r 的单位是次，两者必须来自同一条统计链，绝不能一个取台账、一个取工单。

3.2 总运行时间与点估计：扣除停机时间后才是真运行时间

累计运行时间 T 是 MTBF 计算书里最容易被注水的数字。日历时间 8,760 小时是设备挂在现场的时间，不是设备真正在运行的时间。计算 T 的常见做法是：逐台读取设备的运行计时器，或者用日历时间逐台扣除计划保养时长、待机时长、故障停机时长。以这批设备为例，单台日历 8,760 小时，扣除计划保养 360 小时、待机 2,000 小时、故障停机与其他非运行时间 180 小时，得到单台运行 6,220 小时，50 台合计 311,000 小时。

有了 T 和 r，指数分布下的点估计就是一次除法：

• 故障率 λ = r / T = 8 / 311,000 ≈ 2.57 × 10⁻⁵ 次/小时
• MTBF 点估计 = T / r = 311,000 / 8 = 38,875 小时

这个 38,875 小时是「基于现有样本的最佳猜测」，但它没有表达不确定性。8 次故障的样本量很小，真实 MTBF 可能比它低很多，也可能高很多。所以计算书的正文里必须同时给置信区间，不能只写一个干巴巴的点估计。

顺带算一下单台年故障率：6,220 / 38,875 ≈ 0.16 次/年，也就是平均每台设备约 6.25 年出一次故障。这个数在维修策略里很有用，但同样只是期望值，不能理解成「这台设备保证 6 年不坏」。

3.3 用卡方分布算置信区间，并在计算书里写明自由度

指数分布下 MTBF 的置信区间有标准公式，用的是卡方分布。这里的关键不是背公式，而是搞清楚自由度，我见过不少人在这里翻车。对于置信水平 1-α，双侧置信区间的通式是：

• 下限 = 2T / χ²(α/2, 2r+2)
• 上限 = 2T / χ²(1-α/2, 2r)

以 90% 置信水平为例，α = 0.1，r = 8，自由度分别是 2r+2=18 和 2r=16。查卡方分布表，上侧 0.05 分位点 χ²(0.05, 18) ≈ 28.869，上侧 0.95 分位点 χ²(0.95, 16) ≈ 7.962。代入计算：

• 下限 = 622,000 / 28.869 ≈ 21,546 小时
• 上限 = 622,000 / 7.962 ≈ 78,122 小时

也就是说，在 90% 置信水平下，真实 MTBF 落在 21,546 到 78,122 小时之间。这个区间宽度超过 3.6 倍，恰好说明样本量不足，盲目相信点估计是危险的。计算书里应该写一句「本次统计故障次数较少，置信区间较宽，建议持续积累数据后复算」。

如果统计期内一次故障都没有，r=0 时不能套上面的双侧公式。常见做法是计算单侧置信下限：MTBF 下限 = 2T / χ²(α, 2)。以 α=0.1、T=311,000 为例，χ²(0.1, 2)=4.605，下限 ≈ 135,071 小时。但这里要特别提醒：无故障数据算出来的下限通常非常乐观，甲方容易误读为「保证值」，我会在计算书里额外加一行注明这是统计推断，不是质保承诺。

用脚本验算一遍也是个好习惯，避免查表抄错：

from scipy.stats import chi2 T = 311000 # 累计运行时间，小时 r = 8 # 有效故障次数 alpha = 0.1 # 显著性水平，对应90%置信 # 双侧置信区间，注意 ppf 是下侧分位点 lower = 2 * T / chi2.ppf(1 - alpha / 2, 2 * r + 2) upper = 2 * T / chi2.ppf(alpha / 2, 2 * r) print(f"MTBF点估计: {T/r:.0f} h") print(f"90%置信区间: {lower:.0f} ~ {upper:.0f} h")

注意上面代码里 ppf 的入参：因为 scipy 的 ppf 计算的是下侧分位点，所以 2r+2 自由度对应的上侧 0.05 要写成 1 - alpha/2。很多人不理解这一点，直接把 0.05 传进去，算出来的下限会被严重低估。建议每份计算书的置信区间结果都写清楚所用的分位点方向和自由度，方便复核。

4. 数据来源怎么选：现场统计、试验数据、参考标准各有各的用法

4.1 三类数据源对比：决定计算书可信度的是数据链

MTBF 计算书的可信度，本质上由数据链的可追溯性决定。工程上常见的数据源有三类，各有适用场景，不能混为一谈。现场统计数据的优点是真实反映使用环境，缺点是周期长、判据乱，而且统计期间产品可能已经改过版。实验室试验数据的优点是条件可控、周期短，缺点是加速因子怎么定有争议，外推到现场工况有偏差。参考标准预计数据的优点是无样机时也能算，缺点是它代表「行业平均失效率水平」，不代表你的产品真实水平。

我做计算书的原则是：能用现场数据就不用预计值，能用实测就不用类比。标准预计只在两个场景下使用，一是产品还没有样机、投标需要填一个数；二是现场数据少到不足以支撑统计推断，需要拿预计值做参照。无论用哪种，计算书里都要明确写出数据来源，不能含糊地写「根据行业经验」。

4.2 故障判据要写进计算书：哪些算故障，哪些不算

「故障」的定义如果不写清楚，统计出来的 r 值就是一笔糊涂账。工程上常用的判据是：设备丧失规定功能，或性能指标超出允许范围，且需要更换零部件或调整后才能恢复。按这个原则，下面这些情况通常应计入故障：功能性停机、性能超差导致报警停机、必须更换元器件才能恢复的损坏。下面这些通常不应计入：计划内保养、耗材更换、外部电源波动引起的停机、操作失误导致的急停、软件主动升级后的重启。

比较难处理的是「间歇性故障」和「软故障」。某台设备一个月内随机重启了三次，每次重启后自检正常，最后定位是电源模块接触不良。这种算几次故障？我的处理方法是：如果同一个根因导致的多次重启，按一次故障计，故障修复时间从第一次异常开始算；如果是不同根因，各算一次。这条规则要写进计算书的数据处理说明里，否则审计时无法自圆其说。

还有一个容易被忽略的点：维修策略会影响故障记录。有些现场为了快速恢复，把整个板卡换掉，故障件送修后再装回去；有些现场则是现场修电阻电容。这两种方式下，故障次数可能一样，但故障时间点和维修时长的统计口径不同。计算书里要写明「故障次数以根因定位为准，不以更换动作次数为准」。

4.3 数据量不够时，宁可用预计法也不要编现场数据

现场统计最尴尬的情况是：设备确实在跑，但运维台账几乎没有有效记录。我见过有人拿「印象中坏过两三次」这种说法填进计算书，最终被评审追问「故障时间点是什么时候、故障代码是什么、维修工单号是什么」时完全答不上来。

这种情况下，正确的做法是切换到预计法，并且明确声明。拿整机拆解成模块级或元器件级清单，查行业标准里的失效率数据，按串联模型累加，再乘环境系数和质量系数，得到设计 MTBF。这样算出来的值可能比现场感受偏保守，但至少每条数据都有出处、可复核。等运行数据积累到一定程度（经验上累计运行时间达到预计 MTBF 的 2 到 3 倍，且故障次数不少于 5 次），再更新为现场统计值。

如果是产品从未量产、只有几台样机做过短时测试，连预计法都不够扎实。这时候常见的做法是引用同类在售产品的现场统计数作为先验参考，在计算书里明确标注「类比自某同类产品，未经本型号验证」。类比数据的价值在于给决策者一个量级参考，而不是伪造精度。

5. 计算书返工避坑：五条实际踩过的数据坑

5.1 只写点估计不写置信区间，评审必问

现象：计算书正文写「MTBF = 38,875 小时」，没有任何区间或不确定性说明。评审只问了一句「这个数准吗」，编制人答不上来，整章重写。 原因：点估计是一个单一数字，看似精确，实则掩盖了样本量不足的事实。8 次故障对应的 90% 置信区间跨了 3.6 倍，单写一个数字等于把不确定性全部隐藏。 处理：从第一次写计算书开始，就养成「点估计 + 置信区间 + 样本量」三件套的习惯。样本量不足时加一句「建议持续积累数据复算」，不要试图用更多小数位假装精确。

5.2 日历时间当运行时间，数字虚高一倍以上

现象：某同行统计 50 台设备一年，直接 50 × 8,760 = 438,000 小时计入计算。实际设备每天只运行 8 小时、周末停机，真实 T 只有约 120,000 小时，MTBF 被高估近 3 倍。 原因：把「设备挂在现场的时间」当成了「设备运行的时间」。对于非连续运转设备，待机、关机、保养、故障停机都混进了分母。 处理：计算书的数据说明里单独列一张表，写清楚每类时间的扣除规则。能读到运行计时器就读计时器，读不到就按工况占比折算，但必须写明折算依据。

5.3 故障判据没定义，数据被推翻重审

现象：统计口径是「维修工单数量」，结果一次雷击导致 8 台设备同时损坏，工单一次开了 8 张，故障次数直接飙到 16 次，MTBF 跌到 19,000 小时。 原因：没有把「同一根因、多台同时故障」的处理规则写进计算书。按工单数计还是按根因计，结果完全不同。 处理：计算书里固定一条规则：同一时间、同一外部原因导致的批量故障，根因相同则计为一次事件，但故障设备台数要在附注里写明。这样既不影响 MTBF 的量级判断，也保留了事件全貌。

5.4 所有设备套指数分布，耗损期算出来的数没人信

现象：某机械类设备故障间隔时间明显随役龄缩短，前一年平均 8,000 小时一次，第三年变成 3,000 小时一次。直接用指数分布算 MTBF，算出来的数字越往后越乐观，维修部门按这个数备件，结果严重缺货。 原因：耗损失效期故障率上升，指数分布「故障率恒定」的假设不成立。 处理：先用威布尔概率图拟合 β 值。β 明显大于 1 时，改用威布尔模型，并且把 MTBF 按役龄分段给出；计算书里不能只给一个全生命周期均值。

5.5 置信水平乱标，同一份数据能差一倍

现象：同一份数据，前一版写 90% 区间 21,546 到 78,122 小时，后一版改成 95% 区间后下限掉到约 18,300 小时，评审发现两个版本数字对不上，怀疑数据造假。 原因：置信水平变了却没有同步更新说明，甚至连复核人都没注意到。90% 和 95% 的区间差异在工程上不是小数目。 处理：计算书首页写明本次采用的置信水平，区间数字、假设、自由度全部对应。中途改置信水平必须整表重算并留版本记录，不许只改区间数字。

6. 计算书交付之后：从 MTBF 反推 MTTR、备件与维修周期

6.1 从 MTBF 到年故障次数：把可靠性数字换算成维修工作量

计算书不是写完就归档的文件，它最实际的价值是指导维修策略。拿到 MTBF 之后，第一件事是换算成年故障次数期望值。以第 3 章的例子来说，50 台设备、单台年运行 6,220 小时、MTBF 点估计 38,875 小时，全现场年期望故障次数就是 50 × 6,220 / 38,875 ≈ 8 次。注意这个 8 正好等于统计期内的故障次数，不是巧合，因为它就是用同样的 T 和 r 推出来的。

这个换算的真正用处是和 MTTR 合起来算可用度。假设平均修复时间 MTTR 为 4 小时，单台可用度 A = MTBF / (MTBF + MTTR) ≈ 38,875 / 38,879 ≈ 0.9999。很多工程师看到这个数字就觉得「可靠性很好」，但实际上全现场每年仍有 8 次故障，每次故障可能影响生产线的某一段。可用度高不等于维修工作量小，设备数量一多，小概率事件也会变成日常事务。

6.2 按泊松分布定备件数量：用 MTBF 反推库存水位

年期望故障次数是 λ，在故障率近似恒定的假设下，未来一年内发生 k 次故障的概率服从泊松分布。要决定备多少件，不是直接备 λ 件，而是定一个「不缺件概率」，再反推备件数。年期望 8 次故障、希望 95% 的年份不缺件，查泊松分布累积表或直接用统计函数，得到 k=13 时累积概率约 96.7%，k=12 时约 93.6%。也就是说关键备件按 13 件准备，可以覆盖绝大多数年份的需求。

这里有一个经验上的修正：泊松分布假设故障相互独立，但实际中雷击、电网波动这类共因失效会让故障成簇出现。所以我在算完理论库存后，会额外加 10% 到 20% 的安全余量，同时在备件策略里注明「共因失效风险较高的站点，建议按站点单独堆少量备件，而不是集中放中心仓」。这个修正不算精确计算，但能避免最尴尬的场面——好几台设备同时坏，备件库却只有一件。

做了这么久计算书，我的习惯是：每一份计算书交付时都附一页「数字使用说明」，写清楚 MTBF 是统计期望、置信区间是多少、年故障期望是多少、备件建议怎么定。这样使用方不会把 MTBF 当成寿命承诺，维修部门也能直接拿数字干活。希望你下次写计算书时，能一次通过评审，不用再返工。希望帮到你。

本文还有配套的精品资源，点击获取