3. 自主任务平台总体架构设计

自主任务平台不是把若干算法模块简单堆叠在一起，而是围绕“任务如何被理解、分解、分配、执行并闭环”这一主线，把感知、决策、规划、控制、通信与本体接口组织成可替换、可扩展、可验证的分层系统。总体架构设计的核心目标，是让上层任务逻辑与下层无人系统本体解耦：平台负责“想清楚做什么、怎么分工、何时干预”，本体负责“稳定地执行运动与动作”，两者通过明确定义的接口交换指令与状态。

一、分层架构：从任务语义到执行动作

推荐采用五层结构，自顶向下依次为任务层、决策规划层、执行控制层、通信中间层和本体接口层。任务层接收任务描述（如“对区域A执行搜索并回传目标坐标”），完成任务解析、约束提取与优先级排序；决策规划层把任务拆成子任务序列，进行任务分配、航路/路径规划与冲突消解；执行控制层把规划结果转成速度、航向、高度、云台角、开关量等可执行指令，并做限幅、平滑与安全约束；通信中间层负责消息路由、QoS、时间同步与断链处理；本体接口层则对接飞控、底盘、机械臂、载荷等具体设备。

分层的价值在于“变更隔离”：更换一种无人平台时，只需替换本体接口层与少量执行控制适配；调整任务策略时，主要修改任务层与决策规划层，不必触碰底层控制。层间只允许相邻层直接调用，跨层访问必须通过接口代理，避免形成难以维护的网状依赖。

二、模块划分与职责边界

在层内进一步划分模块，建议至少包含：任务管理模块、态势融合模块、任务分配模块、路径规划模块、行为决策模块、运动控制模块、载荷控制模块、通信管理模块、健康管理模块与日志回放模块。任务管理维护任务状态机（待命、下发、执行、暂停、完成、异常）；态势融合把多源感知统一到同一时空基准；任务分配输出“谁在何时去何处做什么”；路径规划输出带时间戳的轨迹；行为决策处理动态障碍与规则约束；运动控制与载荷控制分别面向平台运动和任务载荷；健康管理监控电量、链路、传感器与执行机构状态。

模块之间应通过“能力”而非“实现”交互。例如任务分配模块只关心某平台是否具备“到达指定点并悬停”的能力，而不关心它是多旋翼还是固定翼。这样新增平台类型时，只需注册能力描述，无需修改分配算法。

三、接口定义：三类关键接口

接口是架构能否落地的关键。建议明确三类接口：任务接口、控制接口和状态接口。任务接口采用结构化任务描述，字段包括任务ID、类型、目标点、时间窗、优先级、约束条件与完成判据；控制接口采用统一指令集，如速度指令、位置指令、航向指令、载荷开关与参数设置；状态接口按固定频率上报位姿、速度、电量、链路质量、任务进度与故障码。

接口设计要遵循三条原则：一是显式单位与坐标系，位置统一用WGS-84或局部ENU，速度用m/s，角度用rad或deg并注明；二是版本兼容，接口带版本号，新增字段向后兼容；三是超时与重试策略明确，指令下发后若在T毫秒内未收到确认，则按幂等重发或降级处理。

四、数据流与控制流

数据流是“自下而上”的：传感器与本体状态经通信中间层汇聚到态势融合，形成统一环境与平台状态，供决策规划使用。控制流是“自上而下”的：任务层生成任务，决策规划层生成子任务与轨迹，执行控制层生成指令，经通信中间层下发到本体接口，最终驱动执行机构。两条流在健康管理与日志模块汇合，用于监控与复盘。

需要特别注意的是控制流的闭环：本体执行后产生的状态变化会再次进入数据流，形成“指令—执行—状态—修正”的闭环。若只关注下行指令而忽略上行状态，平台就会变成开环系统，无法应对风扰、负载变化或通信抖动。

五、平台与无人系统本体的关系

平台与本体是“指挥—执行”关系，但并非单向命令。平台向本体下发的是经过约束校验的指令，本体向平台回传的是真实状态与执行结果。两者之间应保持“松耦合、强契约”：松耦合指平台不依赖某型本体的内部实现，强契约指接口字段、频率、超时和异常码必须严格一致。

在实际工程中，常用“能力注册表”描述本体：每个平台注册自身可执行的动作类型、最大速度、续航、载荷能力与通信协议版本。平台在任务分配时查询能力注册表，只有满足任务约束的平台才进入候选集。这样，当新增一台无人车或无人机时，只需补充注册信息，任务分配与规划逻辑无需改动。

六、设计检查要点

完成架构设计后，建议用以下问题自查：层间是否存在跨层直连？接口是否带版本与单位？控制指令是否有确认与超时？状态上报频率是否满足闭环控制需求？断链后平台与本体各自进入什么状态？任务完成判据是否可观测？若这些问题都有明确答案，架构就具备了从设计走向集成的基本条件。