2. 航天器任务与需求分析

航天器架构不是先画方框图再往里填功能，而是从任务需求出发，逐层推导出“必须有哪些功能、这些功能由谁承担、彼此如何连接、受什么限制”。任务与需求分析的核心作用，就是把一句模糊的任务目标，转化为可分解、可验证、可映射到分系统的工程输入。本节围绕任务剖面、飞行阶段、功能需求、性能指标与约束条件五类输入，说明它们如何共同驱动架构设计。

一、任务剖面：把任务目标展开为可分析的事件序列

任务剖面描述航天器从发射到任务结束所经历的主要事件及其环境、工作模式和持续时间。它不是简单的时间线，而是架构设计的“工况清单”。例如一颗太阳同步轨道遥感卫星，其任务剖面通常包含：发射段、入轨与早期轨道段、在轨测试段、常规成像运行段、数传与测控段、轨道维持段、离轨或退役段。每个阶段对应不同的姿态、供电、热控、通信和数据处理需求。

任务剖面直接决定架构中的模式划分。以成像运行段为例，卫星需要在目标上空完成侧摆、成像、数据记录，并在过站时下传。若任务要求“单圈内完成成像并实时下传”，则数据流架构必须支持成像载荷到数传分系统的高带宽直通路径；若允许“先存储、后下传”，则可引入大容量固态存储器，降低对实时链路的要求。可见，同一颗卫星因任务剖面不同，架构选择会明显分化。

二、飞行阶段：识别环境与工作状态的切换边界

飞行阶段是任务剖面的时间切片，但架构设计更关注阶段之间的切换边界。发射段以力学环境为主，要求结构、连接与锁紧装置能承受振动、噪声和加速度；入轨段涉及星箭分离、太阳翼展开、天线展开等一次性动作，要求火工品、展开机构和状态确认逻辑可靠；在轨运行段以热、辐射、微流星和长期供电为主，要求热控、电源和自主管理能力；离轨段则要求推进或阻力装置具备可控的末段能力。

阶段切换点往往是架构中最容易出问题的地方。例如太阳翼展开前后，供电架构从“蓄电池单独供电”切换为“太阳翼与蓄电池联合供电”，配电模块需要具备母线电压调节和浪涌抑制能力。若在架构设计时未把展开瞬间的功率冲击纳入指标，就可能出现母线跌落导致星务计算机复位。因此，飞行阶段分析要输出的是：每个阶段的持续时间、环境条件、工作模式、关键事件和切换条件，这些信息最终会落到分系统的接口与冗余设计上。

三、功能需求：从任务目标到功能树的分解

功能需求回答“航天器必须做什么”。通常采用功能树方式逐层分解：第一层是任务级功能，如“获取地面目标图像并回传”；第二层是系统级功能，如“姿态指向”“成像采集”“数据存储”“数据下传”“能源供给”“热环境维持”；第三层是分系统级功能，如“星敏感器定姿”“反作用飞轮执行”“固态存储器写入”“行波管放大”“太阳翼分流调节”。功能树越清晰，架构映射越直接。

功能分解的关键是区分“必须由航天器自主完成”和“可由地面配合完成”。例如姿态确定，若星上自主定姿能力不足，就需要地面测控站频繁注入姿态数据，这会增加测控弧段需求，进而影响通信架构。功能需求还要标注功能之间的依赖关系：成像功能依赖姿态稳定，姿态稳定依赖电源和星务管理，星务管理依赖测控与数据管理。这些依赖关系构成架构中的信息流与能量流骨架。

四、性能指标与约束条件：架构的量化边界

性能指标是可测量的目标值，约束条件是架构不可逾越的边界。二者共同决定分系统的规模与接口。常见指标包括：轨道高度与倾角、地面分辨率、幅宽、重访周期、数据速率、存储容量、姿态指向精度、姿态稳定度、供电功率、母线电压、热控温度范围、寿命与可靠性。约束条件则包括：运载火箭包络与质量上限、发射力学环境、成本与进度、频轨资源、测控站分布、星上处理器算力与功耗、元器件等级与国产化要求。

指标与约束之间经常冲突。例如提高分辨率需要增大口径或降低轨道高度，前者增加质量与包络，后者缩短寿命并提高热控难度。架构设计就是在这些冲突中寻找可行解。一个实用的做法是建立“指标—约束—架构影响”对照表，把每项指标落到具体分系统，并标注其约束来源。例如“数据速率 900 Mbps”会驱动数传分系统选择 Ka 频段、高增益天线和高效调制方式；“总质量不超过 1200 kg”则限制结构、推进和载荷的分配额度。

五、从需求到架构：建立可追溯的映射链

需求分析的最后一步是建立“需求—功能—分系统—接口—验证”的追溯链。以“地面分辨率优于 1 m、幅宽不小于 30 km、单圈成像数据量约 120 Gbit”为例，其映射过程如下：分辨率与幅宽决定相机焦距、探测器像元数和轨道高度；数据量决定存储容量与数传速率；数传速率又决定天线增益、发射功率和调制编码方式；发射功率和天线质量反过来影响电源分系统与结构分系统。若其中任一环节超出约束，就需要回到需求层重新权衡，例如降低幅宽、提高压缩比或增加地面站接收能力。

在实际工程中，常用需求追溯矩阵记录这种映射。矩阵的行是任务需求，列是分系统或接口，单元格填写分配指标、验证方法和责任人。这样，当某一项指标发生变更时，可以快速定位受影响的分系统和接口，避免“改一处、动全身”的失控。

六、需求变更对架构的影响

任务需求并非一成不变。发射机会调整、载荷指标升级、测控站布局变化，都会引发需求变更。架构设计需要预留一定的“变更裕度”，例如电源母线预留 15% 功率余量、数据总线预留 20% 带宽余量、结构预留标准安装接口。但裕度不是越大越好，过度预留会挤占质量与成本。合理的做法是识别高风险需求项，对其相关分系统设置可扩展接口，而对低风险项采用紧凑设计。

总之，任务剖面和飞行阶段回答“在什么条件下工作”，功能需求回答“必须完成什么”，性能指标与约束条件回答“做到什么程度、受什么限制”。三者共同构成架构设计的输入空间，架构方案则是这个输入空间中的一个可行解。需求分析越扎实，架构设计越少返工；需求追溯越清晰，后续分系统划分与接口定义就越有依据。