软件质量引发的装备质量事故教训与启示

一、问题的严重性

软件在现代武器装备中已从辅助角色演变为核心使能技术。飞行控制、武器投放、导航定位、战场通信等关键功能高度依赖软件实现。然而，软件在带来能力跃升的同时，也引入了传统硬件可靠性工程难以完全覆盖的新型失效模式。正如相关研究所指出的，“我们的软件密集型技术能力与我们对其如何失效或导致事故的理解之间，正在形成一道日益扩大的安全鸿沟”。传统事故调查方法在追溯软件失效根源时往往力不从心——软件不像硬件那样随时间磨损老化，其缺陷在设计阶段即已嵌入，可能在特定条件组合下突然激活，造成灾难性后果。

二、典型事故案例剖析

案例一：Ariane 5运载火箭首飞失败（1996年）

Ariane 5火箭在首次飞行约40秒后因惯性参考系统软件故障而自毁。事故根因在于软件复用：Ariane 5沿用了Ariane 4的惯性平台软件，但Ariane 5的飞行轨迹与Ariane 4存在显著差异，导致对齐过程中产生超出预期的横向速度值。该数值在转换为16位有符号整数时发生溢出，触发软件异常并使主、备份计算机同时失效。关键教训在于：软件复用不能脱离运行环境进行简单移植，复用组件的集成测试必须在新的运行环境中完整执行。此外，安全关键功能（如自毁判断）的软件应具备足够的数值健壮性，不能假设输入值永远处于设计范围内。

案例二：Therac-25放射治疗机事故（1985—1987年）

Therac-25是一台由软件控制的放射治疗设备，在两年间因软件缺陷导致六名患者受到严重过量辐射，多人死亡。事故暴露出多个层面的软件质量问题：一是软件需求缺陷——几乎所有软件相关事故的根本原因都在于需求层面而非编码实现层面，但当时的安全标准几乎全部聚焦于实现阶段的保证活动；二是过度信任软件替代硬件安全联锁，设计人员消除了硬件保护措施而完全依赖软件控制安全关键功能；三是将可靠性等同于安全性，忽略了软件安全性高度依赖于使用环境和上下文。

案例三：美军无人艇软件故障（2025年）

2025年5月，美国海军在加州海岸进行大规模无人艇测试，投放并回收超过30艘无人艇，其中十多艘未能完成任务。这些无人艇拒绝接收指令、自动进入故障保护状态，最终失去动力沉没。同年6月和7月的后续测试中，又发生无人艇突然加速撞翻支援快艇、以及无人艇相撞坠海等事故。知情人士指出，这些事故均源于软件故障与人为失误的叠加效应，包括船载系统与外部自主控制软件之间的通信中断。这一案例表明，在软件密集型自主武器系统中，软件缺陷与人机交互设计的薄弱环节相互叠加，可能产生远超单一故障的连锁效应。

案例四：F-16飞控软件在跨声速区失效

某型战斗机在完成武器系统升级后的测试中，遥测数据显示飞机计算机在特定空速（马赫1附近）全部失效并重启。飞行员因飞机具有足够动量和机械备份控制而未察觉异常。根因追溯至气动力学方程的一个固有特性——该方程在马赫1处渐近趋于无穷大。气动专家知晓这一假设，但软件工程师并不理解方程背后的物理含义，系统工程接口人员也未意识到需要传递这一假设信息，最终软件工程师仅将方程直接编码而未绘制其行为曲线。这一事故揭示了跨学科接口中“知识盲区传递”的系统性风险。

三、共性根因分析

3.1 需求缺陷是首要根因

综合多起事故的分析，需求层面的缺陷——而非编码错误——是导致装备软件事故的最主要因素。机载雷达软件质量研究表明，利用故障模式统计分析和帕累托法则对软件功能性、可靠性等问题进行分析后，软件需求问题被确定为影响雷达软件质量最关键、频次最多的原因。安全关键软件领域的研究也得出类似结论：几乎所有软件相关事故都涉及需求缺陷而非实现错误，但现行标准仍过度聚焦于实现保证，对安全关键需求的识别与验证投入不足。

3.2 软件复用中的验证盲区

Ariane 5和Therac-25均涉及软件复用。Ariane 5直接复用了Ariane 4的软件组件但未充分验证其在新运行环境中的行为；Therac-25的软件曾在Therac-20上使用，相同的缺陷在Therac-20上因硬件保护设计而未造成危害，但在Therac-25上因硬件保护被移除而暴露为致命缺陷。这提示我们：软件组件的“历史可靠性”不能替代在新环境中的独立验证。

3.3 跨学科接口的假设传递失效

F-16飞控软件事故典型地反映了多学科协作中隐含假设传递失败的问题。当软件工程作为系统工程的一个环节介入时，上游学科（如气动力学、控制理论）的专业假设往往未被明确文档化，软件工程师由于缺乏领域知识而无法自行识别这些隐含约束。这一问题的系统性解决方案在于：在需求规格中显式记录各学科的基本假设、适用范围和边界条件。

3.4 人机协同中的软件失效放大

美军无人艇事故表明，软件故障的后果在高度自主化系统中可能被放大。当软件进入故障保护状态后，操作员被迫转向手动控制，而手动控制与自动控制之间的切换本身又引入了新的风险。这一案例呼应了软件在军事航空事故中的研究结论——传统事故调查方法在识别软件的因果作用方面存在系统性盲点，事故报告中经常忽略软件对事件升级的贡献。

四、启示与对策

启示一：将安全关键需求识别作为独立的工程活动

不应将软件安全性简单等同于“满足需求”。需要建立专门的安全关键需求识别过程，在系统开发早期就明确哪些软件功能具有安全关键属性，并针对这些功能开展独立的安全性分析与验证。GJB 5000B中原因分析与问题归零的实践要求为此提供了可操作的框架。

启示二：建立“假设显式化”的跨学科需求规格规范

针对F-16案例暴露的问题，在涉及多学科接口的软件需求文档中，应强制要求记录：各学科方程或模型的适用条件与边界、输入参数的合理范围与异常处理策略、以及物理量单位和精度的约定。边界假设应直接用于生成测试用例，以覆盖常规测试难以触及的奇异性条件（如除零、边界穿越、奇异点等）。

启示三：软件复用必须伴随环境适配验证

任何软件组件的复用决策都应附带明确的环境差异分析报告，复用组件在新系统环境中的集成测试不可省略。GJB 5000B现场评价中已发现重用资产管理不规范的问题，包括未建立重用资产库、未对重用资产进行必要评审等。装备软件研制单位应将复用资产的入库、出库、版本管理等环节纳入配置管理的强制要求。

启示四：把软件质量监督延伸到全生命周期

GJB 4072B—2023《军用软件质量监督要求》的实施经验表明，当前软件产品质量监督中仍存在需求分析管理薄弱、外场软件更改记录简略、外部供方质量管理滞后等突出问题。需要紧扣“一头一尾”——即需求源头管理和外场使用端反馈——构建覆盖需求、设计、编码、测试、部署、维护全过程的软件质量监督链条。

启示五：事故调查必须纳入软件专家与软件因果分析

传统事故调查体系对软件失效的识别能力严重不足。多项研究建议，事故调查报告中应设立专门的软件分析章节，软件专家应作为调查组的正式成员参与全过程，并将软件系统的因果作用追溯至开发与采办链条中的系统性因素，而非止步于操作层面的“人为失误”。

五、结语

装备软件质量事故的教训反复表明：软件不是“不会坏”的技术，其失效模式恰恰因其不可见性和环境依赖性而比硬件更为隐蔽。从Ariane 5的数值溢出到Therac-25的安全联锁缺失，从F-16的跨声速方程奇异性到无人艇的通信中断，每一起事故都指向软件工程化能力的薄弱环节。将软件质量从“事后检测”转向“设计嵌入”，将安全关键需求从“隐式假设”转为“显式规格”，将事故调查从“硬件主导”拓展为“软硬并重”，是提升装备软件质量、防范灾难性事故的必由之路。