简介这份资源面向电气工程专业学生、电力系统运维人员及可靠性分析初学者聚焦电气系统与设备的可靠性评估方法帮助读者在设计、制造、运行与维护各阶段建立量化评估思路。内容围绕可靠性定义与MTBF、MTBR、故障率等衡量指标展开涵盖故障树分析、事件树分析、FMEA、可靠性预测与寿命数据分析等常用方法并延伸至冗余设计、状态监测、预测性维护、风险评估及IEC、IEEE、GB等标准规范的应用要点。资源包共16个文件以12个m脚本文件为主体辅以2个txt说明、1个md文档和1个license授权文件整体约16KB轻量便于快速查阅与二次开发。目前已有144人学习下载适合希望系统梳理可靠性评估流程、对照代码理解蒙特卡洛仿真与序列/非序列抽样实现的读者参考。1. 电气代码 086 可靠性评估从一堆 Excel 到能写进报告的结论手里拿到一个叫「电气代码086 可靠性评估.zip」的压缩包第一反应往往不是兴奋而是发懵——里面大概率是几十个 Excel、几份 PDF 说明书外加一堆命名随意的 csv。真正要解决的问题很具体给定一批电气设备断路器、变压器、接触器、母线的历史故障记录和运行台账怎么算出一套能写进评估报告的可靠性指标而不是拍脑袋说「这套系统比较可靠」。可靠性评估在电气领域不是新概念但落到代码层面绝大多数人卡在三个地方指标定义不统一MTBF 到底按运行小时还是日历小时算、数据清洗没有标准流程停机记录和故障记录混在一起、算完之后不知道怎么解释λ 值 0.003 次/年到底算好还是差。这个方向适合电气运维工程师、做设备状态评价的技术员以及需要给甲方交付可靠性分析报告的人。下面按「数据怎么整 → 指标怎么算 → 结果怎么验」的顺序把一套能复现的流程讲清楚。2. 可靠性评估的数据底座先把台账洗成能算的格式2.1 电气设备可靠性数据的三种来源与取舍做 086 这类可靠性评估数据来源通常有三类。第一类是设备台账记录型号、投运日期、安装位置用来算设备台年和运行小时。第二类是故障/缺陷记录包含故障时间、故障类型、处理时长、是否强迫停运这是算故障率和 MTBF 的核心。第三类是检修记录用来区分「计划停运」和「非计划停运」——很多人算可靠性时把计划检修也当成故障结果 λ 值虚高一大截。常见做法是把三类数据合并成一张「设备-事件」宽表每行代表一次状态变化事件。字段至少要有设备编号、事件类型投运/故障/修复/计划检修、事件时间、持续时长、故障部位。这里有个血泪经验故障记录里的时间字段经常是「2023.5.12 上午」这种非标准格式直接丢给 pandas 会变成 object 类型后面算时间差全部报错。清洗阶段必须统一成 ISO 格式。提示如果台账里同一台设备有多次改造或更换建议按「设备编号投运批次」拆成多条记录否则 MTBF 会被历史数据稀释。2.2 用 pandas 做故障记录清洗的最小脚本下面这段代码处理的是最常见的场景一张故障记录表时间列格式混乱停运时长用分钟记录需要转成小时并剔除计划检修。import pandas as pd import numpy as np # 读取原始故障记录假设文件名为 fault_raw.csv df pd.read_csv(fault_raw.csv, encodinggbk) # 统一时间格式兼容 2023/5/12、2023-05-12、2023.5.12 三种写法 def parse_time(s): s str(s).strip().replace(., -).replace(/, -) return pd.to_datetime(s, errorscoerce) df[event_time] df[故障时间].apply(parse_time) # 停运时长统一转小时原始列可能是分钟 df[duration_h] pd.to_numeric(df[停运时长], errorscoerce) / 60.0 # 剔除计划检修事件类型字段里含「计划」二字的行 df df[~df[事件类型].str.contains(计划, naFalse)] # 剔除时间解析失败和时长为空的行 df df.dropna(subset[event_time, duration_h]) # 按设备编号和时间排序方便后续算间隔 df df.sort_values([设备编号, event_time]).reset_index(dropTrue) print(df[[设备编号, event_time, duration_h]].head(10))逻辑说明parse_time函数用替换加to_datetime兜住三种常见分隔符errorscoerce保证解析失败的行变成 NaT 而不是抛异常。duration_h除以 60 是因为多数台账用分钟记录停运时长而可靠性指标MTBF、MTTR习惯用小时。剔除计划检修这一步最关键它直接决定后面算出来的是「故障率」还是「停运率」。参数说明encodinggbk针对国内 Excel 导出的 csv 常见编码如果报 UnicodeDecodeError 就换utf-8-sig。errorscoerce可以改成errorsraise来定位具体哪一行格式有问题调试阶段建议先用 raise。2.3 运行小时与台年别用日历时间糊弄算故障率 λ 的分母是设备运行小时数不是日历小时数。一台变压器投运 3 年但中间停了 4 个月运行小时应该是 3×8760 减去停运时长而不是直接 3×8760。常见做法是逐台设备累加从投运日期到评估截止日期减去所有停运事件的 duration_h 总和。如果台账里没有精确的投运日期只有投运年份那就按年中投运估算并在报告里注明假设。这一步的误差会直接传导到 λ 值上所以评估报告里必须写清楚运行小时的统计口径。我一般会在脚本里单独输出一张「设备运行小时汇总表」方便和甲方核对。3. 核心指标计算MTBF、λ、可用率的代码实现3.1 MTBF 和故障率 λ 的公式选择与单位陷阱MTBF平均故障间隔时间的公式看起来简单总运行小时 ÷ 故障次数。但坑在于「故障次数」怎么数。同一台设备一次故障后修了三次才好算 1 次还是 3 次行业里通常按「强迫停运事件」计数一次停运算一次不管修了几轮。如果按维修工单数MTBF 会偏小。故障率 λ 是 MTBF 的倒数单位是「次/小时」。但报告里更常写「次/年」需要乘以 8760。这里有个单位陷阱如果 MTBF 算出来是 12000 小时λ 就是 1/12000 8.33e-5 次/小时换算成年是 0.73 次/年。很多人直接拿 1/12000 当「次/年」写进报告差了三个数量级。可用率 A 的公式是 MTBF / (MTBF MTTR)其中 MTTR 是平均修复时间等于总修复时长 ÷ 故障次数。可用率是个无量纲比值通常写成百分比。注意 MTTR 只算修复时长不含等待备件和管理审批的时间如果台账里把等待时间也算进停运时长MTTR 会虚高可用率偏低。3.2 逐设备计算可靠性指标的完整脚本下面这段代码在清洗后的数据基础上按设备编号分组计算 MTBF、λ、MTTR 和可用率。import pandas as pd # 假设 df 是 2.2 节清洗后的数据另有一张设备台账表 device_info.csv dev pd.read_csv(device_info.csv, encodinggbk) dev[投运日期] pd.to_datetime(dev[投运日期], errorscoerce) # 评估截止日期 eval_end pd.Timestamp(2024-12-31) results [] for _, row in dev.iterrows(): did row[设备编号] sub df[df[设备编号] did] # 运行小时 投运到截止的日历小时 - 总停运小时 calendar_h (eval_end - row[投运日期]).total_seconds() / 3600.0 downtime_h sub[duration_h].sum() run_h calendar_h - downtime_h # 故障次数 强迫停运事件数 n_fault len(sub) if n_fault 0 and run_h 0: mtbf run_h / n_fault lam_year (1.0 / mtbf) * 8760 mttr downtime_h / n_fault avail mtbf / (mtbf mttr) else: mtbf, lam_year, mttr, avail None, 0.0, None, 1.0 results.append({ 设备编号: did, 运行小时: round(run_h, 1), 故障次数: n_fault, MTBF_h: round(mtbf, 1) if mtbf else None, lambda_次每年: round(lam_year, 4), MTTR_h: round(mttr, 2) if mttr else None, 可用率: round(avail, 4) }) res_df pd.DataFrame(results) res_df.to_csv(reliability_result.csv, indexFalse, encodingutf-8-sig) print(res_df)逻辑说明循环遍历每台设备先算日历小时再减去停运小时得到运行小时。n_fault直接用子表行数因为清洗阶段已经剔除了计划检修剩下的就是强迫停运。当故障次数为 0 时MTBF 无定义λ 记为 0可用率记为 1.0这是工程上的惯例处理。参数说明eval_end是评估截止日期必须和甲方确认不同截止日期算出的 λ 不可比。round的位数按报告要求调整λ 建议保留 4 位小数可用率保留 4 位。输出用utf-8-sig是为了 Excel 打开不乱码。3.3 系统级可靠性串联与并联模型的简化处理单台设备的指标算完后如果要做系统级评估比如一条馈线由断路器电缆变压器串联组成需要用到可靠性框图。串联系统的故障率是各单元 λ 之和可用率是各单元可用率之积。并联系统冗余配置的等效故障率近似为 λ1×λ2×(MTTR1MTTR2)这个公式在冗余电源评估里很常用。实际项目中我一般不会对所有设备都建框图而是挑关键回路做。因为串联模型假设各单元独立故障但电气系统里共因故障比如同一段母线失压导致下游全部停运很常见直接套串联公式会低估系统故障率。处理办法是在报告里单独说明共因故障的影响或者用 β 因子模型做修正但那个复杂度就上去了086 这类评估通常用简化处理加定性说明就够了。4. 避坑与排查可靠性评估里最容易翻车的五个地方4.1 现象λ 值算出来是 0但设备明明故障过原因运行小时算成了负数或者故障次数统计时把该设备的事件过滤掉了。常见于设备编号在台账和故障表里格式不一致比如台账是「TR-001」故障表是「TR001」匹配不上导致子表为空。解决在合并前先做编号标准化去掉横杠、空格、转小写。用df[设备编号].str.replace(-, ).str.strip().str.upper()统一格式后再匹配。另外检查run_h是否大于 0如果投运日期晚于评估截止日期日历小时会是负数。4.2 现象MTTR 比 MTBF 还大可用率算出来是负数原因停运时长字段里混入了「等待备件」「等待调度批准」的时间这些不属于修复时间。或者同一时间段被重复记录比如一次故障开了两张工单duration_h 被加了两次。解决在清洗阶段增加一列「是否计入 MTTR」只保留实际维修作业的时长。对于重复记录按设备编号事件时间去重保留第一条。可用率如果算出来小于 0说明 MTBF MTTR 的公式用反了检查是不是把 MTTR 当成了 MTBF。4.3 现象不同批次设备混在一起算λ 值被拉平原因早期投运的设备故障率高后期投运的低混在一起算总 λ 看不出趋势。或者同一型号不同厂家的设备混算掩盖了厂家差异。解决按投运年份或厂家分组分别算 λ 再做对比。如果样本量太小少于 5 台建议合并同类设备但注明样本量。我一般会在报告里放一张「分年度故障率趋势表」比单一 λ 值有说服力得多。4.4 现象评估截止日期不一致两批数据没法比原因第一批数据截止到 2023 年底第二批截止到 2024 年中运行小时基数不同λ 直接比较没有意义。解决统一截止日期或者把 λ 归一化成「次/年」后再比。如果实在没法统一在报告里明确标注各批数据的统计区间不要放在同一张对比表里。4.5 现象代码跑通了但结果和甲方手里的报告对不上原因统计口径不同。甲方可能把计划检修也算进故障次数或者用日历小时当运行小时或者 MTTR 包含了等待时间。解决先对齐口径再算。把公式和字段定义写成一张对照表让甲方确认。这一步花半小时能省掉后面反复返工的两天。血泪经验口径没对齐就出报告改起来比重算还麻烦。5. 结果验证与报告输出让 λ 值站得住脚5.1 用历史数据做回测验证算完 λ 之后别急着写报告。拿同一批设备前一年的数据单独算一次看 λ 是否稳定。如果波动超过 30%说明样本量不够或者数据质量有问题。另一个验证方法是和厂家给出的 MTBF 标称值对比如果算出来差了一个数量级先检查单位再检查是否把早期失效期浴盆曲线的第一段的数据混进来了。对于 086 这类评估我一般会做一张「计算值 vs 标称值」对照表偏差超过 50% 的设备单独标注在报告里说明可能原因运行环境恶劣、维护不到位、数据记录不全。这比直接给一个 λ 值可信得多。5.2 输出一张能直接贴进报告的汇总表最终交付的表格建议包含这些列设备编号、设备类型、投运日期、运行小时、故障次数、MTBF、λ次/年、MTTR、可用率、备注。备注列写数据异常或特殊说明。表格按 λ 降序排列最不可靠的设备排在最前面甲方一眼就能看到重点。如果要做可视化画一张 λ 的横向条形图就够了别搞太花哨的雷达图。电气可靠性评估的读者更关心数值和排序不是图形美观。图表的横轴标注清楚单位是「次/年」纵轴按 λ 从大到小排。5.3 一个容易被忽略的技巧置信区间点估计的 λ 值没有置信区间严格来说是不完整的。对于故障次数较少的设备比如只有 1-2 次故障可以用卡方分布算 λ 的置信区间。公式是λ 的 95% 置信区间为 [χ²(0.025, 2n)/(2T), χ²(0.975, 2n2)/(2T)]其中 n 是故障次数T 是运行小时。这个在 Python 里用scipy.stats.chi2.ppf就能算。我一般只对故障次数少于 3 次的设备算置信区间因为故障次数多的时候区间很窄点估计就够用了。加上置信区间后报告里写「该设备 λ 估计值为 0.73 次/年95% 置信区间 [0.42, 1.18]」比单写一个数专业得多。这个习惯是我做了十几个评估项目后养成的甲方看到区间会觉得你考虑得细而不是在糊弄。希望帮到你。本文还有配套的精品资源点击获取