3. 任务需求分析与指标转化

卫星任务方案权衡的起点，往往不是一组漂亮的轨道参数或平台指标，而是一段来自用户或任务方的自然语言需求。例如“对某区域实现每天至少两次观测，重访间隔不超过 8 小时，图像地面分辨率优于 1.5 m，数据在获取后 2 小时内送达地面站”。这类表述包含目标、频次、时效、精度和交付要求，但还不能直接用于总体设计。任务需求分析的核心工作，是把这些用户语言逐层转化为可计算、可比较、可验证的任务能力指标，同时识别硬约束与软约束，并建立量化的权衡准则。

一、需求分层：从用户目标到工程参数

需求通常可分为三层。第一层是用户目标层，描述“要解决什么问题”，如灾害应急监测、国土普查、海上目标跟踪。第二层是任务能力层，描述系统必须提供的能力，如覆盖范围、重访周期、分辨率、数据时延、定位精度、任务寿命。第三层是工程参数层，描述实现这些能力所需的具体参数，如轨道高度、倾角、回归周期、相机焦距、像元尺寸、星上存储容量、数传速率、地面站可见弧段。需求分析不是简单翻译，而是建立“目标—能力—参数”的映射链，并检查每一层是否可度量、可追溯。

以“每天至少两次观测某纬度带”为例，它首先转化为覆盖能力指标：目标区域在 24 小时内被星下点或侧摆视场覆盖的次数不少于 2 次，且两次观测的时间间隔不超过 8 小时。进一步，它映射到轨道参数：若采用太阳同步轨道，需通过回归特性、升交点赤经和侧摆能力共同决定重访；若采用低倾角轨道，则需评估目标纬度是否在覆盖范围内。此时，用户需求才真正变成可参与权衡的输入。

二、指标转化：把模糊词变成可计算量

需求中常见的“高分辨率”“快速响应”“高可靠”等词，必须转化为带数值、单位、条件和判据的指标。转化时建议同时记录四个要素：指标名称、目标值、门限值、验证条件。目标值是期望达到的水平，门限值是最低可接受水平，验证条件说明在什么轨道、什么光照、什么地面站条件下统计。例如：

• 地面分辨率：目标值 ≤ 1.0 m，门限值 ≤ 1.5 m，验证条件为星下点、太阳高度角 ≥ 30°、无云。
• 重访间隔：目标值 ≤ 6 h，门限值 ≤ 8 h，验证条件为指定纬度带内任意目标点，统计周期 7 天。
• 数据时延：目标值 ≤ 1 h，门限值 ≤ 2 h，验证条件为从成像完成到数据落地并完成预处理。
• 任务寿命：目标值 ≥ 5 年，门限值 ≥ 3 年，验证条件为在轨可用模式下的连续工作时间。

这些指标一旦量化，就能进入后续的轨道、载荷、平台和数传方案比较。需要注意的是，指标之间往往互相牵制：提高分辨率通常要求降低轨道高度或增大口径，这会缩小幅宽、增加重访难度；提高数传速率或增加地面站可降低时延，但会增加成本与资源占用。因此，指标转化必须同步识别耦合关系，而不是孤立地追求单项最优。

三、约束条件：硬约束与软约束分开管理

约束条件决定可行域。硬约束是不可违背的边界，例如运载能力给出的入轨质量上限、整流罩包络尺寸、发射窗口、频段许可、光照条件、测控可见性等。软约束则是可以折中、可以交换的期望，例如成本、研制周期、功耗余量、数传余量、地面站使用费。把两者混在一起，容易在权衡时误把“希望”当成“必须”，导致方案空间被不必要地压缩。

实际工作中，建议为每条约束记录来源、类型、边界值和验证方式。例如“入轨质量 ≤ 800 kg”来自运载方接口文件，属于硬约束，验证方式为质量预算表；“功耗余量 ≥ 15%”来自项目内部设计准则，属于软约束，验证方式为 worst-case 功耗分析。这样在后续方案比较时，任何不满足硬约束的方案直接淘汰，而软约束则进入评分函数参与折中。

四、可量化权衡准则：让比较有共同尺度

当多个方案都能满足硬约束时，就需要用统一的量化准则排序。常用做法是：先对每个指标做归一化，把不同量纲的数值映射到 0～1 区间；再按任务优先级赋权重；最后计算综合得分。归一化时要注意方向：重访间隔、时延、成本属于“越小越好”，分辨率数值越小越好，而寿命、覆盖率属于“越大越好”。对“越小越好”的指标，可采用 score = (max - x) / (max - min)；对“越大越好”的指标，可采用 score = (x - min) / (max - min)。

例如某任务有三个候选方案，重访间隔分别为 5.5 h、6.8 h、7.6 h，分辨率分别为 1.2 m、1.0 m、1.4 m，时延分别为 1.5 h、1.0 h、1.8 h。若权重取重访 0.35、分辨率 0.25、时延 0.20、成本 0.10、寿命 0.10，则可先对每个指标归一化，再加权求和。计算后可能发现：方案二分辨率与时延最优，但重访稍差；方案一重访最好，但分辨率一般。最终得分取决于权重设置，而权重必须来自任务方的优先级确认，不能由设计人员随意指定。

五、从需求到权衡的闭环检查

完成指标转化与约束整理后，应做一次闭环检查：每条用户需求是否都有对应的能力指标？每个能力指标是否都能追溯到至少一个工程参数？每条硬约束是否都有明确的验证方式？权衡准则是否覆盖了任务方最关心的维度？如果发现某条需求无法量化，应回到用户侧澄清；如果发现某条指标没有参数支撑，应补充方案或调整指标。只有形成“需求—指标—参数—约束—准则”的完整链条，后续的轨道、载荷、平台和数传权衡才有可靠依据。

下表给出一个简化的指标转化与约束登记示例，可直接作为任务分析阶段的输入清单使用。

需要强调的是，指标转化不是一次性工作。随着方案迭代，某些指标可能被证明过于苛刻或过于宽松，此时应回到需求层与任务方重新协商，而不是在工程层强行“凑参数”。可量化权衡准则的价值，正在于让每一次折中都有据可查、有数可算、有优先级可依，从而避免方案比较沦为经验之争或口径之争。