2. 航天器任务与故障管理需求分析

冗余配置与故障管理不是凭空设计的，它必须从航天器“要完成什么任务、在什么阶段完成、靠哪些功能完成、完成到什么程度”逐层推导出来。需求分析的核心工作，就是把任务层面的描述转化为可验证、可追踪的工程需求，并最终形成需求追踪矩阵，使每一条冗余与故障管理措施都能回溯到某个任务目标或性能指标。

一、从任务剖面到飞行阶段

任务剖面描述航天器从发射到寿命终结所经历的全部事件序列。以某低轨遥感卫星为例，其任务剖面可划分为：发射段、入轨段、早期轨道段、在轨正常运行段、轨道机动段、载荷成像段、安全模式段和离轨段。每个阶段对航天器的要求不同，故障管理策略也随之变化。

例如发射段航天器处于运载整流罩内，主要承受力学环境，此时星上计算机可能尚未加电，故障管理以地面监测为主；入轨段太阳翼展开、姿态捕获是关键事件，一旦失败任务即告终止，因此太阳翼展开机构、姿态敏感器和推力器通常需要冗余；在轨正常运行段则更关注长期可靠性和单点故障的隔离与恢复。

把任务剖面拆解为飞行阶段后，需要为每个阶段明确：进入条件、关键事件、持续时间、成功判据和失败后果。这一步是后续所有需求提取的基础。

二、关键功能与性能指标的提取

在飞行阶段确定后，进一步识别每个阶段必须维持的关键功能。关键功能的判定标准通常有两条：一是失效会直接导致任务失败或航天器损失；二是失效后无法通过地面干预及时恢复。典型关键功能包括：姿态确定与控制、电源供给、星地测控通信、星务管理、热控以及有效载荷数据存储与下传。

每个关键功能都要对应可量化的性能指标。以姿态控制为例，指标可能包括：三轴姿态确定精度优于0.05°、姿态稳定度优于0.001°/s、姿态捕获时间小于300s。以电源为例，指标包括：母线电压稳定在28±1V、蓄电池组放电深度不超过60%、单翼失效后仍能维持安全模式供电。这些指标既是设计目标，也是故障判据的来源——当遥测参数偏离指标范围时，故障管理逻辑需要做出响应。

三、从功能指标到冗余与故障管理需求

关键功能和性能指标确定后，就可以逐项分析失效模式，并决定冗余配置和故障管理需求。分析时通常回答四个问题：该功能可能以什么方式失效？失效后能否被检测？检测后能否被隔离？隔离后能否被重构或降级使用？

以星务计算机为例，若采用单机方案，一旦发生SEU累积或看门狗复位失败，整星将失去管理能力。因此需求可写为：星务计算机应采用双机热备冗余，主备机之间通过心跳信号互检，当主机连续3个周期未发出心跳时，备机在2s内接管总线控制权。对应的故障管理需求包括：心跳丢失检测、切换指令生成、切换过程不得导致姿控或电源状态丢失。

再以动量轮为例，若某轴动量轮失效，姿态控制能力下降。需求可写为：动量轮采用四斜装构型，任一轮失效后仍能提供三轴控制力矩；故障管理需具备转速异常检测、失效轮隔离和力矩重构分配功能。这里的冗余配置（四斜装）和故障管理（检测、隔离、重构）是配套出现的，缺一不可。

四、需求追踪矩阵的建立

需求追踪矩阵是需求分析的最终交付物，它把任务目标、飞行阶段、关键功能、性能指标、失效模式、冗余配置和故障管理需求串联起来，形成可追溯的链条。矩阵的每一行对应一条需求，每一列对应一个追踪维度。

建立矩阵时，建议从任务目标向下分解，再从底层需求向上回溯验证。向下分解保证不遗漏，向上回溯保证不冗余。矩阵中每条需求应有唯一编号，并标注来源、验证方法和验证阶段。验证方法可以是分析、仿真、测试或在轨数据评估；验证阶段可以是桌面联试、环境试验或在轨测试。

五、矩阵的填写与验证要点

填写矩阵时，每条需求应满足“单一、明确、可验证”的要求。例如“提高系统可靠性”不是合格需求，而“任一陀螺失效后，姿态确定精度仍优于0.05°”才是可验证的需求。验证方法要与需求性质匹配：精度类需求通常用仿真和测试验证，切换时间类需求用故障注入测试验证，长期可靠性类需求用分析和在轨数据评估。

矩阵建立后，还需要做两项检查。第一是覆盖性检查：每个飞行阶段的关键功能是否都有对应的冗余和故障管理需求，是否存在无人负责的失效模式。第二是冲突检查：不同需求之间是否存在资源竞争，例如双机热备的切换时间要求与星务总线仲裁周期是否匹配，冗余供电的切换是否会影响姿控计算机复位。

通过任务剖面分解、飞行阶段划分、关键功能与性能指标提取、失效模式分析，最终形成冗余配置与故障管理需求，并汇总为需求追踪矩阵，这一完整链条保证了航天器故障管理设计“有据可依、有迹可循”。矩阵既是设计输入，也是后续验证和评审的重要依据。