带有软件的作战系统,能按计算机基本可靠性来'预计'吗?

带有软件的作战系统，能按计算机基本可靠性来"预计"吗？

装备质量 ｜ 科普推文 ｜ 2026年6月

点击查看：装备质量推荐GJB相关培训

在一次型号审查会上，有人拿出一份可靠性预计报告："我们的火控计算机MTBF预计值达到了8000小时，所以系统可靠性满足指标要求。"——这句话听起来很合理，但它藏着一个根本性的概念混淆。

核心问题：带有软件的作战系统，其可靠性预计能不能等同于计算机硬件的基本可靠性？答案是：不能。把两者混为一谈，等于只检查了发动机却没检查刹车，就宣称整车安全达标。

一、先搞清楚：什么叫"计算机系统基本可靠性"？

在军用电子设备领域，可靠性预计有一套成熟方法，核心文件就是GJB/Z 299C-2006《电子设备可靠性预计手册》。它的基本思路是：

这个方法的适用对象非常明确——硬件。电路板、电源模块、处理器芯片、存储器、连接器……所有会老化、会磨损、会在温度循环中产生焊点疲劳的物理实体。

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毫无关系。

层面二：可靠性的传递路径不同

在作战系统中，可靠性依赖链大致是这样的：

这是一个硬软交织的链条。根据简单的串联可靠性模型：

哪怕硬件可靠性做到0.9999，软件可靠性只有0.9，系统整体可靠性也上不了0.9。把"计算机系统基本可靠性"当作系统可靠性，相当于只乘了一个因子，漏掉了所有其他因子。

层面三：标准体系各管一摊，不可互相替代

军工可靠性标准体系本身就说明了这一点——如果硬件可靠性预计能覆盖软件，就不会单独设立GJB/Z 161和GJB/Z 102了：

GJB 450B-2021 明确要求对含软件的装备系统进行可靠性分析时，必须同时考虑硬件和软件，并关注两者的交互影响。这不是一个可选项，而是标准明确规定的系统工程要求。

五、那正确的做法是什么？

简单说，三件套：分开评估、综合建模、持续验证。

1. 硬件可靠性——用GJB/Z 299C

2. 软件可靠性——用GJB/Z 161

3. 系统级综合——分统结合

六、一句大实话

回到文章开头那个场景——"火控计算机MTBF 8000小时，所以系统可靠性达标"——这句话问题在哪？

它把可靠性预计的三个层级——元器件→单机→系统——中最薄弱的环节直接跳过了。

MTBF 8000小时只能说明：在GB/T 5080.7或GJB 899A规定的统计置信度下，这台裸机硬件的平均无故障工作时间是8000小时。它不回答以下任何一个问题：

这些问题，没有一个能用MTBF回答。

◆ ◆ ◆

结语

在现代作战系统中，软件早已不是"锦上添花"的辅助角色，而是与硬件同等重要、甚至更加关键的战斗力要素。把软件密集系统的可靠性约化为"计算机基本可靠性"，本质上是用工业时代的思维看待信息时代的装备——只见硬件不见软件，只见机器不见系统。

对于从事装备质量监督和检验验收的同行来说，一个实操建议是：

审查可靠性预计报告时，请多问一句："软件可靠性评估报告在哪？软硬件联合可靠性试验做了没有？"

有时候，一个简单的问题，就能堵住一个系统级隐患。