2. GCS需求分析与任务建模

地面控制站（GCS）的需求不是凭空“想”出来的，而是从无人机要执行的真实飞行任务中“提取”出来的。需求分析的核心工作，是把一段模糊的任务描述，逐步转化为可验证的功能需求、可量化的性能指标、不可逾越的约束条件，以及可驱动软件设计的用例模型。本节以一条典型的测绘巡检任务剖面为主线，完整走一遍这个转化过程。

一、任务剖面：需求的唯一来源

任务剖面（Mission Profile）是对一次完整飞行从起飞到回收的全过程描述，它规定了各阶段的时间、高度、速度、航点、载荷动作和异常处置。需求分析的第一步，就是把任务书翻译成结构化的剖面。假设某电力巡检任务要求：对一段约 12 km 的输电线路进行可见光与红外双光巡检，飞行高度相对地面 80 m，巡航速度 10 m/s，共 24 个航点，每到达一个航点悬停 5 s 并触发双光拍照，全程需在 35 min 内完成，且必须支持一键返航。

把这段描述拆成阶段，可以得到：起飞爬升 → 航线巡航 → 航点悬停拍照 → 返航下降 → 回收。每个阶段都隐含着一组对 GCS 的要求，例如“航点悬停拍照”要求 GCS 能下发航点、触发载荷、接收图像状态；“一键返航”要求 GCS 具备独立于常规链路的应急指令通道。剖面越具体，后续需求越不容易遗漏。

二、从剖面到功能需求

功能需求回答“GCS 必须能做什么”。提取方法是逐阶段追问：这个阶段里，谁需要向谁发出什么信息，系统必须给出什么反馈？以“航线巡航”为例，操作员需要把 24 个航点上传到飞控，GCS 必须提供航线编辑、校验、上传和回读确认四项能力。其中“回读确认”常被忽略，但它决定了操作员能否确认飞控真正收到了航线，而不是只看到本地界面显示成功。

再以“悬停拍照”为例，GCS 需要在到达航点时向载荷发送触发指令，并接收“拍照完成、图像已存储”的状态。由此得到两条功能需求：载荷触发指令下发、载荷状态回传与显示。若任务还要求实时预览，则追加“图像回传与显示”功能。可以看到，功能需求天然带有主语和动作，写成“系统应支持……”的句式，便于后续逐条测试。

三、性能指标的量化

性能指标回答“做到什么程度才算合格”。它必须可测量，否则无法验收。仍以遥测为例，若只说“实时显示遥测”，不同人理解不同；量化为“遥测数据从机载发出到 GCS 界面更新，端到端时延不超过 200 ms，刷新率不低于 5 Hz”，就变成了可测试的指标。

常用指标包括：时延（指令端到端 ≤ 300 ms）、刷新率（遥测 ≥ 5 Hz）、精度（航迹偏差告警阈值 5 m）、容量（单次任务航点 ≥ 100 个）、可用性（任务期间 GCS 无崩溃）。这些数值来自任务剖面的实际约束，而不是拍脑袋。例如 35 min 完成 12 km 巡检，反推出巡航速度约 10 m/s，进而要求 GCS 的航线执行监控刷新率足以让操作员在 1 s 内察觉偏航，这就把刷新率与任务时限联系了起来。

四、约束条件的识别

约束条件回答“哪些边界不能突破”。它通常来自物理、法规和任务三类来源。物理约束如链路中断 3 s 必须自动返航，这是安全底线；法规约束如飞行高度不得超过 120 m；任务约束如单次任务不超过 35 min、图像本地缓存不少于 2 GB。约束条件往往直接决定系统的降级策略：当链路质量下降时，GCS 应降低遥测刷新率以保指令通道，而不是继续满负荷传输图像。

五、用例模型：把需求变成可设计的对象

用例模型回答“谁与系统交互、交互出什么结果”。它把功能需求组织成参与者（Actor）与用例（Use Case）的关系。本任务的参与者有两类：地面操作员和 GCS 自身（作为自动处置的执行者）。操作员相关的用例包括：规划航线、上传航线、启动任务、监视遥测、处置告警、一键返航、导出数据。系统自动用例包括：链路中断自动返航、低电量告警、图像自动归档。

每个用例还应附带基本流与异常流。以“上传航线”为例，基本流是：操作员编辑航点 → GCS 校验航点间距与高度 → 上传飞控 → 飞控回读 → GCS 显示“上传成功”。异常流包括：航点间距小于安全阈值时拒绝上传并提示；上传超时后自动重试一次，仍失败则提示检查链路。把异常流写清楚，后续测试用例就有了直接来源。

六、一份可填写的需求提取表

把上述过程固化成一张表，可以在实际项目中直接使用。下表以本任务为例，给出需求提取的示例字段与内容，其中数值均为教学示例，实际项目应按任务书核定。

这张表的价值在于：每一行都能追溯到剖面中的具体阶段，每一列都对应后续设计中的一类工作——功能需求驱动界面与指令设计，性能指标驱动通信与调度设计，约束条件驱动安全与降级设计，用例模型驱动模块划分与测试用例编写。需求分析做到这一步，GCS 的软件架构才有了可靠的输入，而不是靠经验拼凑。