3. 无人系统任务生命周期与状态划分

无人系统的任务执行不是“按下开始、等待结束”这么简单。无论是无人机巡检、无人车配送，还是无人艇测绘，任务从接收到结束往往要经历多个阶段，每个阶段对系统的控制权限、传感器配置、通信策略和安全约束都有不同要求。如果把这些阶段笼统地当作“运行中”处理，就会出现暂停后无法安全恢复、异常时误判为完成、终止时资源未释放等工程问题。因此，任务生命周期需要被显式地划分为一组可管理、可观测、可切换的状态，并为每个状态定义清晰的进入条件、退出条件和允许的动作。

一、任务生命周期的工程化含义

任务生命周期指的是一个任务从被系统接纳到最终结束所经历的状态序列及其迁移规则。这里的“任务”不是单个控制指令，而是一段具有明确目标、约束和结束条件的作业，例如“对A区3条航线各巡检一次并回传图像”。工程化定义要求每个状态至少回答四个问题：系统当前在做什么、允许接收哪些指令、必须维持哪些安全条件、什么事件会触发状态切换。

与软件线程状态不同，无人系统任务状态还必须考虑物理世界的不可逆性。例如飞行器一旦起飞，暂停通常意味着悬停或盘旋，而不是冻结；地面无人车暂停可以原地驻车，但若停在坡道则需额外制动策略。因此，状态定义必须与平台能力绑定，不能只做抽象建模。

二、八个核心状态的划分

结合工程实践，可将任务生命周期划分为八个核心状态：任务准备、启动、执行、暂停、恢复、完成、异常与终止。它们并非简单线性排列，而是存在多条迁移路径。

• 任务准备（Preparing）：任务已下发但尚未进入动作阶段。系统进行航点/路径解析、参数校验、传感器自检、电量与通信链路检查、地理围栏加载。此状态允许修改任务参数，不允许执行机构动作。
• 启动（Starting）：从准备到执行的过渡态。系统解锁、上电执行机构、进入起始位姿或起始航向，并建立任务时钟。启动失败应回到准备或进入异常，而不是直接执行。
• 执行（Executing）：任务主体阶段。系统按计划推进，周期性上报进度、位置、剩余里程/航时和关键传感器状态。此状态只接受暂停、终止和紧急指令。
• 暂停（Pausing）：受控中止推进但保留任务上下文。无人机悬停、无人车驻车、无人艇保持位置。暂停期间应维持最低安全功耗和通信心跳。
• 恢复（Resuming）：从暂停回到执行的过渡态。系统需重新校验安全条件（电量、定位、链路、障碍），确认后从断点继续，而不是从头开始。
• 完成（Completed）：任务目标已达成且执行机构已安全收束。系统保存结果、释放资源、生成任务记录。完成是正常终态。
• 异常（Fault）：检测到不可忽略的故障或越界，如定位丢失、电量低于返航阈值、通信中断超时、进入禁飞区。异常可尝试降级处置，但必须显式记录。
• 终止（Terminated）：任务被主动取消或异常后无法继续，系统进入安全收束流程并释放资源。终止是另一类终态，与完成区分开，便于统计与复盘。

三、状态迁移关系

八个状态之间并非任意可达。典型迁移包括：准备→启动→执行；执行↔暂停；暂停→恢复→执行；执行→完成；执行/启动/恢复→异常；异常→终止或异常→恢复（降级后）；任意非终态→终止。需要特别注意的是，暂停不能直接跳到完成，恢复也不能绕过安全校验直接回到执行。

四、状态定义中的关键工程参数

仅有状态名称不足以支撑实现，每个状态还需要绑定可判定的参数。以下给出一组示例参数，用于说明工程化定义应包含哪些字段。这些数值属于教学示例，实际取值需根据平台和任务类型标定。

五、实现要点与常见误区

在代码实现中，推荐用状态机模式而非大量布尔标志。每个状态对应一个处理函数，迁移由事件驱动，例如 onEnter、onExit、handleEvent。这样能避免“正在执行又同时处于暂停”的矛盾状态。

// 状态迁移表示例（伪代码）
transitions = {
  Preparing: { START_OK: "Starting", CANCEL: "Terminated" },
  Starting:  { UNLOCK_OK: "Executing", FAIL: "Fault" },
  Executing: { PAUSE: "Pausing", DONE: "Completed", FAULT: "Fault", CANCEL: "Terminated" },
  Pausing:   { RESUME: "Resuming", CANCEL: "Terminated" },
  Resuming:  { CHECK_OK: "Executing", CHECK_FAIL: "Fault" },
  Fault:     { DEGRADE_OK: "Resuming", UNRECOVERABLE: "Terminated" }
};

常见误区有三个。第一，把暂停当作执行的特例，导致恢复时无法判断断点位置；第二，异常与终止混用，使任务统计无法区分“正常结束”和“被迫结束”；第三，完成状态未释放资源，造成下一次任务准备时资源冲突。工程上应坚持：每个状态有唯一进入条件、唯一退出条件、明确的允许指令集，并且所有迁移都记录时间戳和触发原因，为后续复盘提供依据。

综上，任务生命周期的工程化定义，本质上是把“任务在做什么”转化为“系统处于哪个可判定状态、允许什么、禁止什么、下一步由什么事件驱动”。只有状态边界清晰，无人系统才能在暂停、恢复、异常和终止等关键环节保持可控与可追溯。