3. 无人系统平台体系结构与协同集成参考模型

多无人系统协同平台不是把若干无人机、无人车或无人船简单“连起来”就能工作。真正决定系统能否扩展、能否互操作、能否稳定协同的,是它背后的体系结构与协同集成参考模型。本节围绕四个核心维度展开:单体平台、协同层级、通信拓扑、计算架构与集成接口关系。理解这四个维度,才能在后续集成中判断“该在哪一层做决策、用哪种链路传数据、把算力放在哪里、接口如何对齐”。

一、单体平台:协同的最小功能单元

单体平台是体系结构中的原子节点,通常由感知载荷、计算单元、通信链路、执行机构、能源与状态管理五部分组成。以一架巡检无人机为例:感知载荷包括可见光相机与激光雷达;计算单元可能是机载嵌入式计算板;通信链路包含数传电台与图传模块;执行机构是飞控与电机;能源与状态管理负责电池、电压、温度与健康状态上报。

单体平台对外暴露的能力可以抽象为一组“能力描述”,例如:

platform_id: UAV-03
type: multirotor
payload: [camera_rgb, lidar_2d]
compute: edge_gpu_8TOPS
comm: [wifi_mesh, lora_backup]
state: {battery: 78%, pos: (x,y,z), health: nominal}
capability: [area_scan, target_track, relay]

这份描述是协同集成的“身份证”。上层协同算法不需要知道电机型号,只需要知道它能否执行区域扫描、能否作为中继、当前电量是否支持任务。单体平台的标准化封装程度,直接决定了后续协同层级能否解耦。

二、协同层级:从单机到集群的分层决策

协同层级描述“决策在哪里发生”。常见参考模型分为四层:

  • 平台级:单体自主控制,如姿态稳定、避障、路径跟踪;
  • 编队级:若干同构或异构平台形成局部编队,完成队形保持、协同搜索;
  • 任务级:面向具体任务分配资源,如“UAV-03 去 A 区扫描,UGV-01 去 B 区采样”;
  • 体系级:跨域、跨任务、跨组织的全局调度与态势融合。

层级不是越多越好。层级增加会带来通信延迟、状态同步开销和故障传播风险。实际集成中常采用“平台级强自主 + 任务级弱中心”的折中:平台级保证单机安全,任务级只做粗粒度分配,避免中心节点成为单点瓶颈。

三、通信拓扑:决定协同的“血管”

通信拓扑直接影响协同的实时性与鲁棒性。常见拓扑包括:

  • 星型:所有节点连到中心节点,适合小规模、中心算力强的场景,但中心故障即全网失效;
  • 网状(Mesh):节点多跳互联,抗毁性强,适合城市或复杂地形,但路由开销大;
  • 分层树:按编队或区域分组,组内 Mesh、组间星型,兼顾规模与效率;
  • 混合拓扑:主链路用 Mesh,备份链路用 LoRa 或卫星,提升容错。

选择拓扑时,要同时看带宽、时延、覆盖半径、节点移动性。例如视频回传需要高带宽,适合星型或分层树;而协同避障的控制指令需要低时延,适合 Mesh 局部直连。实际工程中常采用“控制走低时延链路、数据走高带宽链路”的双通道设计。

四、计算架构与集成接口关系

计算架构决定算力分布。常见模式有:机载边缘计算、地面边缘计算、云端集中计算。机载边缘适合实时避障与目标跟踪;地面边缘适合多机数据融合与任务分配;云端适合大规模历史分析与模型训练。三者通过接口关系串联。

集成接口关系可归纳为三类:

  • 数据接口:传感器数据、状态遥测、任务指令的格式与协议,如 MAVLink、ROS 2 DDS、MQTT;
  • 服务接口:能力调用、任务下发、状态查询,通常以 REST 或 gRPC 暴露;
  • 时间与坐标接口:统一时间基准(如 PTP/NTP)与统一坐标框架(如 WGS-84 或局部 ENU),这是多机协同最容易出问题的地方。
集成中最常见的故障不是算法错误,而是时间不同步或坐标系不一致:两架无人机对同一目标的定位相差数米,往往源于时间戳未对齐或坐标原点定义不同。集成前必须先约定时间基准与坐标框架,并在接口文档中显式声明。

下面用一张参考模型图把四个维度串起来。图中左侧是单体平台的能力封装,中间是协同层级与通信拓扑的对应关系,右侧是计算架构与接口关系,底部标注了关键接口类型。

无人系统平台体系结构与协同集成参考模型 单体平台 感知载荷 计算单元 通信链路 执行机构 能源与状态管理 能力描述封装 协同层级 体系级:全局调度 任务级:资源分配 编队级:队形保持 平台级:自主控制 决策粒度由粗到细 通信拓扑 中心 星型 / Mesh / 分层树 控制低时延 · 数据高带宽 备份链路提升容错 计算架构 机载边缘 实时避障 / 跟踪 地面边缘 融合 / 任务分配 云端集中 训练 / 历史分析 算力按实时性分层 边缘优先 · 云端兜底 集成接口关系 数据接口 MAVLink / ROS 2 DDS / MQTT 遥测、传感器、任务指令 服务接口 REST / gRPC 能力调用、任务下发、状态查询 时间与坐标接口 PTP / NTP · WGS-84 / ENU 统一时间基准与坐标框架

五、参考模型的实际使用方式

在真实集成项目中,可以按以下顺序使用该参考模型:

  1. 先定义单体平台能力描述,明确每个平台能提供什么、需要什么;
  2. 再确定协同层级,判断哪些决策放在平台级、哪些上收到任务级;
  3. 根据层级选择通信拓扑,控制链路与数据链路分开设计;
  4. 最后对齐计算架构与接口,把实时任务放在边缘,把重计算放在地面或云端,并统一时间与坐标接口。

例如一个“无人机 + 无人车”协同巡检示例:无人机负责高空快速扫描,无人车负责地面精细采样。平台级各自完成避障与定位;任务级由地面站分配“无人机扫描 A 区、无人车在 B 区待命”;通信采用分层树,无人机与地面站用高带宽图传,无人车与地面站用低时延数传;计算上,无人机机载做目标检测,地面边缘做多源融合,云端做历史对比。接口上统一使用 ROS 2 DDS 传输状态,用 gRPC 下发任务,时间基准统一为 PTP,坐标统一为局部 ENU。这样,四个维度就形成了一个可落地、可扩展的协同集成参考模型。

集成前建议先画一张“平台—层级—拓扑—接口”对照表,把每个平台的能力、所属层级、通信方式和接口协议写清楚。这张表比任何架构图都更能暴露集成风险。