4. 资源耗尽故障模式与影响分析

星载计算机的资源耗尽不是单一故障，而是一类由“资源供给—资源消耗—资源回收”三者失衡引发的系统性失效。要把它分析清楚，必须借助两类互补的方法：FMEA（故障模式与影响分析）自底向上枚举“某个资源被谁耗尽、后果是什么”，FTA（故障树分析）自顶向下追问“系统级失效由哪些资源耗尽路径组合而成”。本节围绕这两条主线，给出可落地的分析流程、关键路径判定准则和单点故障识别方法。

一、先建立资源分类与失效判据

FMEA 的第一步不是画表，而是把“资源”定义到可观测、可判据的粒度。星载计算机通常可归为五类资源，每类都要给出明确的耗尽判据，否则分析会停留在“内存不足”这类无法验证的描述上。

判据中的数值属于教学示例，实际型号应依据任务剖面、余量设计和在轨遥测统计确定。判据一旦确定，FMEA 的“故障模式”就有了可测的触发条件。

二、FMEA：从资源条目到影响链

面向资源耗尽的 FMEA，建议以“资源条目 × 消耗者”为分析单元，而不是以整机为单位。每个分析单元至少填写：故障模式、触发原因、局部影响、上层影响、严酷度（S）、发生概率（O）、可检测性（D）以及现有防护措施。RPN = S×O×D 用于排序，但星载场景下更应优先关注严酷度高的单点，而不是单纯追求 RPN 数值最小。

以“堆内存耗尽”为例，其影响链可以这样展开：某图像压缩任务因输入帧异常增大而反复申请大块内存 → 堆碎片化加剧 → 其他任务 malloc 失败 → 姿态控制任务无法创建周期作业 → 控制输出停更 → 星上进入安全模式。这条链中，真正致命的不是“压缩任务申请失败”，而是“姿态控制任务被连带拖死”，后者才是需要重点设防的传播路径。

三、FTA：把系统级失效还原为资源耗尽路径

FTA 从顶事件出发，例如“星载计算机在轨失去姿态控制能力”。向下分解时，资源耗尽类底事件通常以“与门”形式汇聚：只有当“资源被耗尽”与“防护未生效”同时成立，顶事件才会发生。这正是资源耗尽故障的典型结构——单一资源紧张往往不致命，致命的是“耗尽 + 防护失效”的组合。

下面这张图给出了一条典型的资源耗尽故障树片段，同时标注了关键路径与单点故障位置。图中菱形表示未继续展开的底事件，矩形表示中间事件，带“SPOF”标记的底事件为单点故障候选。

四、关键路径与单点故障的判定准则

故障树画完后，真正决定加固优先级的是两条判定准则。

关键路径判定：从顶事件向下，若某条路径上所有底事件同时发生的概率高于 10⁻⁴/年，且路径中不存在冗余或降级措施，则该路径为关键路径。关键路径上的资源条目应优先设置监控点和阈值告警。例如上图中“堆内存耗尽 → 资源被耗尽 → 与门 → 顶事件”就是一条典型关键路径。

单点故障判定：若某个底事件单独发生即可导致顶事件，且无任何冗余、无降级、无自动恢复，则它是单点故障（SPOF）。资源耗尽类 SPOF 常见于三类位置：唯一的堆分配器、唯一的看门狗喂狗任务、唯一的降级决策模块。识别出 SPOF 后，处理策略只有三种——增加冗余、增加降级、增加可检测性，三者至少要落实一项。

五、可执行的 FMEA 分析表模板

下面给出一份可直接填写的资源耗尽 FMEA 分析表，字段按星载场景裁剪，去掉了与本节无关的管理字段。表中“示例行”用于说明填写粒度，实际分析时应逐资源条目展开。

资源条目：堆内存（总 8 MB，余量设计 30%）
--------------------------------------------------------------
故障模式    触发原因          局部影响        上层影响         S  O  D  RPN  现有防护
--------------------------------------------------------------
堆耗尽     图像任务异常帧    压缩任务失败    姿态任务创建失败  9  4  3  108  无内存配额
堆碎片化   大小块交替申请    大块申请失败    周期任务抖动      7  5  4  140  无碎片整理
分配器死锁 中断中调用malloc  系统挂起        看门狗复位        10 2  5  100  禁止中断分配
--------------------------------------------------------------
关键路径：堆耗尽 → 姿态任务创建失败 → 失去姿态控制
SPOF：分配器死锁（无冗余、无降级、检测依赖看门狗）
建议措施：为姿态任务预留静态内存池；分配器加超时返回；增加堆余量遥测

填写时注意三点：一是“触发原因”要写到可复现的操作或条件，而不是“软件缺陷”；二是 S、O、D 的取值要有型号内的统一标度，避免不同人打分口径不一致；三是“现有防护”必须写实际已实现的措施，规划中的措施应另列一栏，否则会高估当前健壮性。

六、从分析结果到测试用例

FMEA/FTA 的产出不应止于一张表，而应直接转化为测试用例。对每条关键路径和每个 SPOF，至少设计一个注入用例：用故障注入工具在目标资源上制造耗尽条件，观察系统是否按预期降级、是否触发告警、是否在限定时间内恢复。例如针对“堆耗尽”关键路径，可注入“连续申请 1 KB 块直至失败”，预期结果是姿态任务仍能从静态内存池获得资源、系统上报堆余量告警、且不触发整机复位。若实际结果是整机复位，则说明该路径的防护未生效，需要回到 FMEA 表更新防护措施并重新验证。

这样，FMEA/FTA 就不再是文档工作，而成为连接“故障模式识别”与“健壮性测试用例设计”的桥梁：分析给出该测什么，测试给出防护是否真的有效，两者迭代闭环，才能把资源耗尽风险控制在可接受范围内。