企业官网建设流程全解析

简介：这份资源面向电气工程专业学生、电力系统运维人员及可靠性分析初学者，聚焦电气系统与设备的可靠性评估方法，帮助读者在设计、制造、运行与维护各阶段建立量化评估思路。内容围绕可靠性定义与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", encoding="gbk") # 统一时间格式：兼容 2023/5/12、2023-05-12、2023.5.12 三种写法 def parse_time(s): s = str(s).strip().replace(".", "-").replace("/", "-") return pd.to_datetime(s, errors="coerce") df["event_time"] = df["故障时间"].apply(parse_time) # 停运时长统一转小时，原始列可能是分钟 df["duration_h"] = pd.to_numeric(df["停运时长"], errors="coerce") / 60.0 # 剔除计划检修：事件类型字段里含「计划」二字的行 df = df[~df["事件类型"].str.contains("计划", na=False)] # 剔除时间解析失败和时长为空的行 df = df.dropna(subset=["event_time", "duration_h"]) # 按设备编号和时间排序，方便后续算间隔 df = df.sort_values(["设备编号", "event_time"]).reset_index(drop=True) print(df[["设备编号", "event_time", "duration_h"]].head(10))

逻辑说明：parse_time函数用替换加to_datetime兜住三种常见分隔符，errors="coerce"保证解析失败的行变成 NaT 而不是抛异常。duration_h除以 60 是因为多数台账用分钟记录停运时长，而可靠性指标（MTBF、MTTR）习惯用小时。剔除计划检修这一步最关键，它直接决定后面算出来的是「故障率」还是「停运率」。

参数说明：encoding="gbk"针对国内 Excel 导出的 csv 常见编码，如果报 UnicodeDecodeError 就换utf-8-sig。errors="coerce"可以改成errors="raise"来定位具体哪一行格式有问题，调试阶段建议先用 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", encoding="gbk") dev["投运日期"] = pd.to_datetime(dev["投运日期"], errors="coerce") # 评估截止日期 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", index=False, encoding="utf-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×(MTTR1+MTTR2)，这个公式在冗余电源评估里很常用。

实际项目中，我一般不会对所有设备都建框图，而是挑关键回路做。因为串联模型假设各单元独立故障，但电气系统里共因故障（比如同一段母线失压导致下游全部停运）很常见，直接套串联公式会低估系统故障率。处理办法是在报告里单独说明共因故障的影响，或者用 β 因子模型做修正，但那个复杂度就上去了，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, 2n+2)/(2T)]，其中 n 是故障次数，T 是运行小时。这个在 Python 里用scipy.stats.chi2.ppf就能算。

我一般只对故障次数少于 3 次的设备算置信区间，因为故障次数多的时候区间很窄，点估计就够用了。加上置信区间后，报告里写「该设备 λ 估计值为 0.73 次/年，95% 置信区间 [0.42, 1.18]」，比单写一个数专业得多。这个习惯是我做了十几个评估项目后养成的，甲方看到区间会觉得你考虑得细，而不是在糊弄。

希望帮到你。

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