夜雨聆风带有软件的作战系统，能按计算机基本可靠性来"预计"吗？
装备质量 ｜ 科普推文 ｜ 2026年6月
在一次型号审查会上，有人拿出一份可靠性预计报告："我们的火控计算机MTBF预计值达到了8000小时，所以系统可靠性满足指标要求。"——这句话听起来很合理，但它藏着一个根本性的概念混淆。
核心问题：带有软件的作战系统，其可靠性预计能不能等同于计算机硬件的基本可靠性？答案是：不能。把两者混为一谈，等于只检查了发动机却没检查刹车，就宣称整车安全达标。
一、先搞清楚：什么叫"计算机系统基本可靠性"？
在军用电子设备领域，可靠性预计有一套成熟方法，核心文件就是GJB/Z 299C-2006《电子设备可靠性预计手册》。它的基本思路是：
• 统计每种元器件（电阻、电容、集成电路、连接器等）的失效率；
• 根据环境应力（温度、振动、电应力等）修正失效率；
• 按串并联模型累加，得到整机的MTBF（平均故障间隔时间）。
这个方法的适用对象非常明确——硬件。电路板、电源模块、处理器芯片、存储器、连接器……所有会老化、会磨损、会在温度循环中产生焊点疲劳的物理实体。
GJB 451A-2005对"基本可靠性"的定义也佐证了这一点：
基本可靠性——产品在规定的条件下，规定的时间内，无故障工作的能力。其度量参数通常是MTBF（平均故障间隔时间）或失效率。
注意，这里的"产品"指的是硬件产品。因为只有硬件才谈得上"故障间隔"——电阻烧了、电容击穿了、焊点开裂了，这些都是可观测的物理故障事件。
二、软件可靠性：完全不同的"物种"
如果把硬件可靠性比作机械磨损，那么软件可靠性更像是地图上的错误标注——它不会因使用而褪色，但你每次按地图走都可能走进死胡同。
GJB/Z 161-2012《军用软件可靠性评估指南》给出了软件可靠性的正式定义：
在规定的条件下和规定的时间内，软件不引起系统失效的能力。软件可靠性不仅与软件存在的缺陷有关，而且与系统输入和系统使用有关。
软硬件在可靠性上的本质差异，可以归纳为几个根本维度：
| 失效机理 | ||
| 失效规律 | ||
| 时间特性 | ||
| 维修方式 | ||
| 核心指标 | ||
| 评估依据 |
一个最直观的差异：硬件会"老死"，软件不会。你的计算机电源模块可能在第50000小时烧毁，但那段代码——假如刚写好时能正确运行——永远不会因为"运行了太久"而出错。它出错，一定是因为遇到了编写时没考虑到的特定输入组合或运行时状态。
三、一个血淋淋的案例：F-35的"蓝屏"
F-35 TR-3软件升级事故
2024年，洛克希德·马丁为F-35开发的TR-3软件——包含数千万行代码——与新硬件严重不兼容，频繁出现死机、黑屏、系统重启等"蓝屏式"故障。
后果：
• 约250架新交付F-35仅能安装阉割版训练软件
• 火控、雷达融合、电子战、武器挂载——四大核心作战功能全部锁死
• 这些号称"全球最强"的战机，实际沦为高级教练机
• Block 4升级推迟至少6年，修复承诺模糊至"2027年前"
注意一个关键事实：这些F-35的计算机硬件没有坏——电路板完好、处理器在跑、电源正常供电。故障的不是硬件，是软件。如果按"计算机系统基本可靠性"来评估，这250架飞机的硬件MTBF一切正常——但它们无法作战。
这个案例残酷地说明：硬件"健康"≠系统"能用"。
四、为什么不能简单等同？——从三个层面看
层面一：失效逻辑不同
计算机硬件的基本可靠性模型假设的是随机物理失效——某个元器件由于制造缺陷或环境应力，在某天突然失效。这是概率性的，服从指数分布或Weibull分布。
而软件失效是系统性、确定性的。一个特定输入，每次都会触发同一个bug。它不存在"概率性不触发"——条件满足了就一定触发。
你把一个MTBF=8000小时的火控计算机拿去跑导弹发射流程，硬件好好的——但软件里有个竞态条件（race condition），在特定时序下会计算出错误的目标坐标。这个失效跟MTBF毫无关系。
层面二：可靠性的传递路径不同
在作战系统中，可靠性依赖链大致是这样的：
传感器硬件 → 信号处理软件 → 数据处理硬件 → 决策算法软件 → 火控硬件 → 显示/操控软件这是一个硬软交织的链条。根据简单的串联可靠性模型：
R系统 = R硬件 × R软件 × R接口 × R人因 × …哪怕硬件可靠性做到0.9999，软件可靠性只有0.9，系统整体可靠性也上不了0.9。把"计算机系统基本可靠性"当作系统可靠性，相当于只乘了一个因子，漏掉了所有其他因子。
层面三：标准体系各管一摊，不可互相替代
军工可靠性标准体系本身就说明了这一点——如果硬件可靠性预计能覆盖软件，就不会单独设立GJB/Z 161和GJB/Z 102了：
| 装备系统 |
GJB 450B-2021 明确要求对含软件的装备系统进行可靠性分析时，必须同时考虑硬件和软件，并关注两者的交互影响。这不是一个可选项，而是标准明确规定的系统工程要求。
五、那正确的做法是什么？
简单说，三件套：分开评估、综合建模、持续验证。
1. 硬件可靠性——用GJB/Z 299C
• 建立完整的元器件清单与应力剖面
• 按环境类别（GF地面固定 / NS舰船 / AIF战斗机座舱等）选取修正系数
• 计算硬件子系统的MTBF
2. 软件可靠性——用GJB/Z 161
• 在配置项测试和系统测试阶段系统收集失效数据
• 选用合适的软件可靠性增长模型（如Jelinski-Moranda模型、GO模型等）
• 基于实际失效数据估计当前可靠度，预测未来可靠性水平
3. 系统级综合——分统结合
• 建立包含硬件的物理失效模型和软件的缺陷激活模型的联合可靠性框图
• 特别关注软硬件接口：协议不一致、时序不匹配、数据格式错误等
• 通过软硬件联合可靠性试验暴露交互失效模式
• 持续监控运行中的失效数据，动态更新可靠性评估
六、一句大实话
回到文章开头那个场景——"火控计算机MTBF 8000小时，所以系统可靠性达标"——这句话问题在哪？
它把可靠性预计的三个层级——元器件→单机→系统——中最薄弱的环节直接跳过了。
MTBF 8000小时只能说明：在GB/T 5080.7或GJB 899A规定的统计置信度下，这台裸机硬件的平均无故障工作时间是8000小时。它不回答以下任何一个问题：
• 运行在它上面的火控软件会不会在电磁干扰下计算出错误坐标？
• 软件和硬件的接口协议有没有隐藏的时序死锁？
• 操作员在高压态势下误操作时，软件会不会进入不可恢复状态？
• 软件升级引入新功能后，有没有激活一个之前沉睡的缺陷？
这些问题，没有一个能用MTBF回答。
◆ ◆ ◆
结语
在现代作战系统中，软件早已不是"锦上添花"的辅助角色，而是与硬件同等重要、甚至更加关键的战斗力要素。把软件密集系统的可靠性约化为"计算机基本可靠性"，本质上是用工业时代的思维看待信息时代的装备——只见硬件不见软件，只见机器不见系统。
对于从事装备质量监督和检验验收的同行来说，一个实操建议是：
审查可靠性预计报告时，请多问一句："软件可靠性评估报告在哪？软硬件联合可靠性试验做了没有？"
有时候，一个简单的问题，就能堵住一个系统级隐患。
参考文献
[1] GJB/Z 299C-2006 电子设备可靠性预计手册 [2] GJB/Z 161-2012 军用软件可靠性评估指南 [3] GJB 451A-2005 可靠性维修性保障性术语 [4] GJB 450B-2021 装备可靠性工作通用要求 [5] 软硬件分统结合的导弹武器装备可靠性评定方法，重庆理工大学学报，2012 [6] F-35 TR-3 Software Upgrade Failure Report, DoD Operational Test & Evaluation, 2024-2025
声明：本文为科普性质，文中技术观点仅供交流探讨，不构成对任何具体型号或产品的评价。
