4. 集群任务数据模型

无人机集群执行一次任务，产生的数据远不止“飞了哪些点”。同一批架次里，既有随时间变化的位姿与链路质量，也有编队结构的动态重组，还有任务阶段切换、异常事件和平台健康状态。如果把这些数据混在一张宽表里，后续做回放、复盘、指标统计和模型训练都会非常吃力。因此，集群任务数据分析的第一步，是建立一套分层的任务数据模型，把“任务怎么走、平台在哪、编队怎么连、发生了什么、当前处于什么状态”这五类信息分别表达清楚，再用统一的时间基准和标识体系把它们关联起来。

任务剖面：把一次任务切成可计算的阶段

任务剖面描述的是任务从起飞到回收的整体阶段划分与阶段目标。它不是简单的航路点列表，而是带有阶段语义的时间区间。一个典型的侦察打击集群任务剖面可以划分为：地面准备、编队集结、区域进入、分区搜索、目标确认、协同打击、战果评估、返航回收八个阶段。每个阶段需要定义阶段标识、起止时间、参与平台集合、阶段目标、进入条件与退出条件。

例如，某次示例任务中，编队集结阶段的进入条件为“全部平台起飞完成且高度稳定在120m±10m”，退出条件为“所有平台进入预定集结空域且队形误差小于15m”。这些条件在数据模型中应表达为可判定的布尔表达式，而不是自然语言描述，否则无法自动切分阶段。阶段切分完成后，后续所有轨迹、事件和状态数据都可以打上阶段标签，便于按阶段做统计对比。

时空轨迹：统一时间基准下的位姿序列

时空轨迹是集群数据量最大的部分。每个平台在每个采样时刻产生一条记录，至少包含：平台ID、时间戳、经度、纬度、高度、速度、航向、姿态角。这里最关键的是时间基准统一。集群内不同平台的时钟可能存在毫秒级偏差，如果直接按各自本地时间拼接，编队拓扑计算会出现虚假的相对位移。工程上通常采用“统一授时+插值对齐”的方式：先以任务主时钟为基准，将各平台轨迹重采样到固定频率（如10Hz），再做时间对齐。

轨迹数据还需要区分绝对轨迹与相对轨迹。绝对轨迹用于航路合规性检查和地理围栏判断；相对轨迹用于编队保持精度评估。相对轨迹通常以编队中心或领航平台为参考点，计算各平台在编队坐标系下的偏移量。参考系定义必须全文一致：本文约定编队坐标系以编队几何中心为原点，X轴指向编队前进方向，Y轴指向右侧，Z轴向上。

编队拓扑：从位置关系到通信与指挥关系

编队拓扑不只是“谁在谁旁边”的几何关系，它同时包含通信链路关系和指挥控制关系。几何拓扑描述平台间的相对位置和队形结构，如楔形、横队、纵队、菱形；通信拓扑描述平台间的链路连接与带宽、时延、丢包率；指挥拓扑描述指令流向和决策权限。三者可能不一致：几何上相邻的两架无人机，通信上可能因为遮挡而链路质量很差，实际指挥关系可能跨级。

在数据模型中，编队拓扑适合用时序图或邻接矩阵表示。每个时刻的拓扑可以表示为一个带权无向图，节点是平台，边是通信链路，边权是链路质量。拓扑变化事件（如节点加入、退出、链路中断、队形重构）应作为独立事件记录，而不是从轨迹中反推。这样在分析编队稳定性时，可以直接统计拓扑变化频率和重构耗时。

事件序列：把“发生了什么”结构化

事件序列是任务数据中最容易被忽视、但对复盘最有价值的部分。集群任务中的事件可以分为几类：平台级事件（起飞、降落、故障、低电量返航）、编队级事件（队形重构、节点加入退出、链路中断恢复）、任务级事件（阶段切换、目标发现、目标丢失、打击执行、评估完成）、异常事件（碰撞告警、通信超时、导航漂移）。

每条事件记录应包含：事件ID、时间戳、事件类型、触发平台、关联平台集合、事件参数、严重等级。事件参数用键值对存储，例如链路中断事件的参数为 {link_id: "L-03", rssi: -92, duration_ms: 1450}。事件序列按时间排序后，可以与任务剖面阶段对齐，形成“阶段—事件”矩阵，用于统计各阶段的事件密度和异常率。

状态表示：平台与任务的双状态机

状态表示解决的是“当前处于什么状态、什么条件下会切换”的问题。集群任务中至少需要两套状态机：平台状态机和任务状态机。平台状态机描述单架无人机的生命周期状态，如待命、起飞、巡航、悬停、返航、降落、故障。任务状态机描述整个集群的任务执行状态，如准备、集结、执行中、暂停、完成、中止。

两套状态机通过条件表达式关联。例如，当任务状态机处于“执行中”时，若超过30%的平台进入“故障”状态，任务状态机应自动切换到“中止”。状态数据在存储时，建议采用“状态快照+状态转移记录”的方式：快照记录某一时刻的全量状态，转移记录只记录变化。这样既能快速恢复任意时刻的状态，又能压缩存储空间。

五层模型的关联与落地

五层模型不是孤立的，它们通过统一关联键连接。任务剖面提供 phase_id，时空轨迹提供 platform_id + timestamp，编队拓扑提供 topology_id，事件序列提供 event_id，状态表示提供 state_snapshot_id。所有层共享 task_id 和统一时间基准。

在实际落地时，建议采用列式存储（如Parquet）按层分表，轨迹表按 task_id + platform_id + timestamp 分区，事件表按 task_id + event_type 分区。查询时通过 task_id 和 timestamp 做跨表关联。这样设计后，回放一段任务只需要按时间范围拉取五张表的数据，按时间轴合并即可；统计编队保持精度只需要轨迹表和拓扑表；分析异常原因只需要事件表和状态表。数据模型清晰了，后续的分析和算法才有稳定的输入。