4. 航空电子软件故障模式

航空电子软件与硬件在故障表现上有本质差异：硬件失效多由物理退化、过应力或环境应力引起，而软件不会“磨损”，其失效几乎都源于设计、实现或需求层面的缺陷。软件在相同输入与相同运行环境下具有确定性，但一旦输入序列、任务调度、接口数据或资源状态发生变化，隐藏缺陷就可能被激活。因此，软件FMEA不能简单照搬硬件FMEA的失效率、寿命分布等概念，而应围绕“缺陷—触发条件—错误传播—系统影响”这条链路展开。

一、软件失效机理：从缺陷到错误的传播

软件失效通常不是单一事件，而是“缺陷被激活→产生错误状态→错误传播→输出异常→系统功能降级或丧失”的链式过程。例如，一个未初始化的指针在多数运行路径中不会被访问，但当某条异常分支被触发时，该指针被解引用，导致数据区被破坏，进而使导航解算输出跳变。这里，缺陷是“指针未初始化”，触发条件是“异常分支执行”，错误是“内存被改写”，失效是“导航输出异常”。

在航空电子中，常见的软件失效机理包括：需求缺陷（需求遗漏、歧义、不一致）、设计缺陷（状态机不完备、并发控制错误、资源分配不当）、实现缺陷（边界条件错误、类型转换错误、算法精度不足）、接口错误（数据格式不匹配、单位不一致、协议时序违反）、时序问题（任务超时、优先级反转、抖动过大）、内存泄漏（动态分配未释放、缓存无限增长）等。这些机理往往相互耦合，例如内存泄漏会加剧时序问题，时序问题又会触发接口超时，形成级联失效。

二、需求缺陷：最上游也最昂贵的故障源

需求缺陷在软件FMEA中应被优先关注，因为需求错误往往在编码阶段无法被完全消除，且越晚发现修复成本越高。典型需求缺陷包括：遗漏必要的安全需求（如未定义传感器失效后的降级策略）、需求歧义（“尽量快速响应”没有量化指标）、需求不一致（同一参数在不同文档中单位不同）、需求不可验证（无法通过测试判定是否满足）。

在FMEA中分析需求缺陷时，不能只写“需求不完整”，而要具体到“哪一条需求缺失、缺失后系统在什么条件下会进入什么状态”。例如，某飞控软件需求规定“当空速传感器数据无效时，切换至备用空速源”，但未规定“若备用源也无效时如何处置”。该缺陷的触发条件是“主备空速源同时失效”，错误状态是“空速值保持上一次有效值或变为默认值”，失效影响是“飞行控制律使用错误空速，可能导致姿态控制异常”。这样的描述才具备可分析性和可验证性。

三、接口错误：数据在边界处最容易出错

航空电子软件通常由多个LRU（航线可更换单元）或分区组成，接口是故障高发区。接口错误可分为数据类、协议类和时序类。数据类包括单位不一致（如角度用度还是弧度）、量纲不匹配、数据范围越界、符号约定相反；协议类包括帧格式错误、校验和错误、字段偏移错误；时序类包括握手超时、采样周期不匹配、消息顺序颠倒。

以ARINC 429总线为例，某软件接收高度数据时，若将BNR编码的符号位处理错误，正负高度会反转。该缺陷在正常飞行高度下可能不触发，但在跨零高度或负高度场景下会输出错误值。FMEA中应记录：接口对象为“ARINC 429高度字”，缺陷为“符号位解析错误”，触发条件为“高度值跨越零点”，错误状态为“高度符号反转”，失效影响为“高度显示与告警逻辑异常”。

四、时序问题与内存泄漏：资源维度的隐性故障

时序问题在综合化航空电子中尤为突出。多个分区共享处理器资源时，若某分区任务执行时间超出预算，会导致其他分区任务超时。优先级反转是典型场景：低优先级任务持有高优先级任务所需资源，中等优先级任务抢占CPU，导致高优先级任务被无限延迟。FMEA中应关注任务周期、执行时间、截止时间、抖动和阻塞时间等参数。

内存泄漏则表现为动态分配的内存未释放或缓存持续增长。在长时间飞行中，泄漏会逐渐消耗堆空间，最终导致分配失败或系统重启。分析时应记录泄漏速率（如每次任务执行泄漏约128字节）、触发条件（特定消息序列）、可观测征兆（堆使用率随时间上升）以及最终影响（内存分配失败、功能丧失）。

五、软件FMEA的特殊性

软件FMEA与硬件FMEA存在若干关键差异。第一，软件没有随机失效率，不能用浴盆曲线描述；软件失效由缺陷和触发条件共同决定，因此分析重点是“缺陷在什么条件下被激活”。第二，软件缺陷不会因更换器件而消失，同一版本软件在相同条件下必然复现，因此FMEA必须与软件版本、配置项和运行剖面绑定。第三，软件失效模式往往表现为功能异常而非物理损坏，严酷度评估需结合系统功能影响，而非仅看软件本身。第四，软件FMEA需要与需求分析、设计评审、代码审查和测试用例设计联动，而不是独立文档。

六、可执行的软件FMEA分析表示例

下表给出一个面向航空电子软件的FMEA分析表片段，字段和内容可根据项目裁剪。表中数据为教学示例，用于说明填写方式，不代表任何真实型号的实测结果。

填写该表时，关键不是字段数量，而是每条缺陷都能追溯到具体的需求、设计或代码位置，并且触发条件和错误状态可被测试或审查验证。软件FMEA的价值在于把“可能出错”转化为“在什么条件下、以什么方式、影响什么功能”的可分析条目，从而支撑后续的测试用例设计、安全论证和适航符合性证据。