2. 系统级任务场景的构成要素

系统级任务场景验证之所以不能停留在“把系统跑一遍”的层面,根本原因在于:一个可验证、可复现、可判定的任务场景,必须由若干相互约束的要素共同定义。缺少任何一个要素,验证结论都会失去边界——要么无法复现,要么无法判定通过与否。本节把任务场景拆解为七个构成要素,并说明它们之间的结构化关系与表达方法。

七个要素的定位与相互关系

任务场景的七个要素并非并列清单,而是有明确的“定义—驱动—约束—判定”层次关系。任务目标是场景的顶层输入,它决定“要验证什么能力”;环境条件与系统状态共同构成场景的初始条件,决定“从什么起点开始”;操作流程是场景的时间主线,决定“按什么顺序施加激励与操作”;约束条件贯穿全程,决定“哪些边界不能越过”;成功准则与失效判据是场景的出口,决定“什么算通过、什么算失败”。

理解这一层次关系非常关键:如果先写操作流程再补任务目标,往往会出现“流程很完整但不知道验证了哪项能力”的问题;如果只写成功准则不写失效判据,则只能证明“做对了”,无法说明“做错了会怎样被识别”。

系统级任务场景七要素结构关系 任务目标 验证哪项系统级能力 初始条件(场景起点) 环境条件 大气/轨道/电磁/温度/地形 系统状态 工作模式/构型/健康/余度 操作流程(时间主线) 激励施加 · 指令序列 · 状态迁移 · 时序关系 约束条件 时间/资源/安全 权限/接口边界 约束条件 贯穿全程 不可越过 场景出口判定 成功准则 指标阈值 · 时序满足 · 状态正确 失效判据 超差 · 超时 · 误动作 · 不可恢复 七要素齐备 → 场景可复现、可判定、可追溯 缺任一要素 → 验证结论失去边界 ▼ 目标决定初始条件的选择 ▼ 初始条件决定流程起点 ▼ 流程执行结果进入判定

任务目标:从能力到可观测指标

任务目标不能写成“验证系统功能正常”这类无法判定的表述。结构化表达要求把目标拆成“能力—条件—指标”三元组。例如,某型无人机任务场景的目标可写为:在链路中断条件下,验证飞控系统自主返航能力,要求返航航线偏差不大于50 m、返航耗时不超过180 s。这里“链路中断”是条件,“自主返航”是能力,“50 m/180 s”是可观测指标。只有落到指标,后续的成功准则才有依据。

环境条件与系统状态:初始条件的两个维度

环境条件描述系统外部的作用因素,包括大气温度、风速、气压高度、电磁干扰强度、地形遮蔽、轨道光照等。系统状态描述系统内部的起始配置,包括工作模式(如巡航/待机/测试)、硬件构型(如余度通道数、载荷挂载状态)、软件版本、健康状态(如电池电量、故障标志位)。

两者必须同时给定,否则场景不可复现。例如“在风速12 m/s、电池电量85%、双余度正常”与“在风速12 m/s、电池电量40%、单余度降级”是两个完全不同的初始条件,即使操作流程相同,验证结论也不可互换。工程上通常用一张初始条件表固化这些参数,并在每次运行前核对。

操作流程:时间主线与激励序列

操作流程是场景中随时间推进的部分,它由若干“激励—响应”步骤组成。结构化表达要求每一步都写清:施加什么激励(指令、故障注入、环境突变)、期望系统产生什么响应、响应应在什么时间窗口内出现。例如故障注入类场景可写为:T=0 s 注入GPS信号丢失;T=0~2 s 系统应检测到导航降级并置位标志;T=2~5 s 应切换至惯导组合导航;T=5 s 后航迹偏差应逐步收敛。

流程中要特别注意时序关系。系统级验证中,很多失效不是“做错了”,而是“做晚了”或“顺序错了”。因此操作流程应显式标注步骤间的先后、并行与超时约束。

约束条件:贯穿全程的边界

约束条件不参与“做什么”,而是限制“怎么做”。常见约束包括:时间约束(场景总时长、各阶段最大耗时)、资源约束(电量、燃料、计算负载、通信带宽)、安全约束(不得进入禁飞区、不得触发不可逆动作)、接口约束(只能通过指定接口注入激励,不得直接修改内部状态)。约束条件必须在场景设计阶段就明确,并在执行过程中被监控,否则验证结果可能因越界而无效。

成功准则与失效判据:场景的出口

成功准则回答“满足什么条件算通过”,失效判据回答“出现什么情况算失败”。两者应成对设计,且都必须是可观测、可判定的。成功准则通常由指标阈值、时序满足性、状态正确性三类组成;失效判据通常包括超差(指标越界)、超时(响应未在窗口内出现)、误动作(不该动的时候动了)、不可恢复(进入无法回到安全状态的分支)。

需要强调的是,失效判据不是成功准则的简单取反。例如“返航偏差不大于50 m”是成功准则,但“偏差大于50 m”只是超差失效的一种;系统还可能在偏差尚可接受时出现链路二次中断且无法恢复,这属于另一类失效。因此失效判据需要独立枚举。

结构化表达的一个实用检查方法:把七个要素写成一张表,逐行检查是否都有明确取值或明确描述。任何一行写“待定”或“视情况而定”,该场景就还不具备可验证性。

结构化表达的落地形式

在实际工程中,七要素通常固化为一份场景定义文件,其字段可参考如下结构(示例为合理假设,非实测数据):

场景编号:SCN-NAV-002
任务目标:链路中断条件下自主返航,航线偏差≤50 m,耗时≤180 s
环境条件:风速12 m/s,温度-10℃,GPS干扰等级中
系统状态:巡航模式,双余度正常,电量85%,软件版本V2.3
操作流程:
  T=0s    注入链路中断
  T=0-2s  检测链路降级并置位
  T=2-5s  切换自主返航
  T=5-180s 执行返航并监控偏差
约束条件:总时长≤200s,不得进入禁飞区,仅通过外部接口注入
成功准则:偏差≤50m 且 耗时≤180s 且 返航后进入悬停
失效判据:偏差>50m 或 耗时>180s 或 未检测到链路降级 或 进入禁飞区

这份文件的价值在于:任何人拿到它,都能在相同初始条件下复现同一场景,并按同一标准判定结果。这正是系统级任务场景验证区别于“试飞体验”的核心所在。

常见错误:把操作流程写得非常详细,却把成功准则写成“系统工作正常”。这类场景执行后无法给出通过/不通过的结论,等于没有验证。另一个常见错误是只写成功准则不写失效判据,导致异常分支被忽略。

总结来看,七要素的结构化表达可以概括为一句话:目标定能力,条件定起点,流程定时间,约束定边界,准则定出口。五者齐备,场景才具备可复现、可判定、可追溯的验证资格。