2. 多飞行器协同系统架构解析

在多飞行器协同HIL测试中,被测对象从来不是单架飞行器的飞控计算机,而是“多机协同系统”这一整体。要设计出可信的HIL测试环境,第一步必须把协同系统的架构讲清楚:谁指挥谁、信息沿什么路径流动、编队几何如何维持、任务如何被分解与执行。本节围绕协同模式、通信拓扑、指挥控制关系与协同任务流程四条主线展开,并给出可直接用于HIL测试建模的架构视图。

一、三种典型协同模式

长机-僚机模式是最基础的协同形态。长机承担任务规划、目标分配与航路决策,僚机以“保持相对位置+执行长机指令”为主要职责。其核心是相对导航:僚机通过数据链获得长机的位置、速度、航向,结合自身惯导/GNSS解算相对位置偏差,再由编队保持控制器生成修正指令。该模式指挥链清晰、实现简单,但长机是单点,一旦长机失效,编队协同能力迅速退化。

编队模式强调几何构型。常见构型包括楔形、横队、纵队与菱形,各机在编队坐标系中拥有固定的期望位置偏移量。编队控制通常采用“长机参考+僚机跟踪”或“虚拟结构法”:前者以真实长机为参考点,后者虚拟出一个编队中心,所有成员跟踪相对该中心的期望位置。编队模式适合区域搜索、协同侦察等需要保持空间覆盖的任务。

蜂群模式则弱化中心节点,强调分布式自治。蜂群通常采用局部规则(如分离、对齐、聚集)或一致性算法,成员仅与邻居交互,通过局部信息耦合涌现出全局行为。蜂群对单点失效鲁棒,但指挥控制关系从“指令下达”变为“规则约束+任务意图注入”,对HIL测试的时序同步与规模扩展提出更高要求。

二、通信拓扑与信息流

协同模式决定逻辑关系,通信拓扑决定物理可达性。工程上常见四类拓扑:星型(中心节点与所有成员直连)、网状(成员间多跳互联)、链式(逐级中继)与混合分层(簇头+成员)。星型时延确定、易于管理,但中心节点带宽与生存性压力大;网状鲁棒性高,但路由与冲突管理复杂;分层拓扑兼顾规模与效率,是蜂群与大规模编队的常用选择。

在HIL测试中,通信拓扑不能只画成“连线”,必须映射为可注入的链路参数:链路时延、丢包率、带宽上限、拓扑切换时刻。例如,将星型拓扑的中心节点链路时延设为20 ms、丢包率0.5%,可复现指挥指令滞后对编队保持精度的影响;将网状拓扑中某条边置为断开,可验证协同系统在链路降级下的重构能力。

多飞行器协同系统架构视图(长机-僚机 / 编队 / 蜂群) 指挥控制层(C2) 任务指挥节点 任务分解 / 目标分配 长机 / 簇头 航路决策 / 编队参考 僚机编队成员 相对位置保持 蜂群自治成员 局部规则 / 一致性 通信拓扑层(链路参数可注入) 中心 星型:时延确定 网状:多跳鲁棒 簇头 分层:规模扩展 链路参数 时延 20ms 丢包 0.5% 带宽 2Mbps 拓扑切换 协同任务流程(HIL可观测节点) 任务分解 目标→子任务 编队生成 期望位置偏移 协同制导 相对导航解算 编队保持 位置/速度修正 任务评估 偏差/重构 协同状态反馈 / 任务重规划

三、指挥控制关系与权限分配

指挥控制关系决定了“谁有权改变任务、谁只能改变自身状态”。在长机-僚机模式中,长机拥有任务级权限,僚机拥有执行级权限;在蜂群模式中,任务意图由指挥节点注入,具体行为由各成员按局部规则自主生成。HIL测试必须把这种权限差异建模为不同的指令通道:任务级指令走低频、高可靠通道,执行级指令走高频、低时延通道。

一个常见的工程做法是引入“协同状态机”,将系统划分为初始化、编队集结、任务执行、链路降级、重构恢复五个状态。状态迁移条件由通信质量、成员健康度与任务完成度共同决定。例如,当某僚机连续3个周期未收到长机心跳,且自身相对导航误差超过阈值,则触发链路降级状态,该僚机切换为自主保持模式,同时向指挥节点上报。

四、协同任务流程与HIL可观测节点

协同任务流程可抽象为“任务分解→编队生成→协同制导→编队保持→任务评估”五个环节。在HIL测试中,每个环节都应设置可观测节点:任务分解环节观测子任务分配表与优先级;编队生成环节观测期望位置偏移量;协同制导环节观测相对导航解算结果;编队保持环节观测位置/速度修正指令;任务评估环节观测编队偏差与重构次数。

以三机楔形编队为例,设长机在编队坐标系中的期望位置为原点,僚机1期望偏移为(-80 m, +60 m, 0),僚机2期望偏移为(-80 m, -60 m, 0)。HIL测试中,将长机航向角以5°/s的速率偏转,观察两架僚机的相对位置偏差是否收敛在±5 m以内。若僚机1在偏转过程中出现超调,则说明编队保持控制器的阻尼参数需要调整;若僚机2响应滞后超过200 ms,则需检查其数据链接收时延与相对导航滤波带宽。

在HIL环境中,建议将通信拓扑的链路参数与协同状态机的迁移条件联合配置。例如,将星型拓扑中心链路丢包率从0.5%逐步提升至5%,观察编队从“正常保持”迁移到“链路降级”再到“重构恢复”的完整过程,从而验证协同系统在通信退化下的鲁棒性。

五、HIL测试架构映射要点

将上述协同架构映射到HIL测试台架时,需要明确三类接口:飞行器模型接口(位置、速度、姿态)、通信链路接口(时延、丢包、带宽)与指挥控制接口(任务指令、状态上报)。每架飞行器的飞控计算机可以是真实硬件,也可以是实时仿真模型;通信链路通常由网络损伤仪或软件模拟器实现;指挥控制节点可由上位机或独立控制器承担。

测试用例设计应覆盖三种协同模式的典型场景:长机-僚机模式下的长机失效重构、编队模式下的构型切换、蜂群模式下的成员增减。每个场景都应记录协同状态机的迁移序列、链路参数变化曲线与编队偏差曲线,作为判断协同系统是否满足设计要求的依据。

注意:协同模式、通信拓扑与指挥控制关系三者必须保持一致。若在蜂群模式下仍采用星型拓扑的中心节点集中调度,则系统实际退化为长机-僚机模式,测试结论将无法反映蜂群自治特性。配置HIL场景时,应先确认逻辑协同模式与物理通信拓扑的匹配关系。

综上,多飞行器协同系统架构解析的核心在于:用协同模式定义逻辑关系,用通信拓扑定义物理约束,用指挥控制关系定义权限边界,用协同任务流程定义可观测节点。只有这四者对齐,HIL测试才能真实复现协同系统在正常、降级与重构状态下的行为,为后续编队控制算法验证与通信协议测试提供可信基础。