4. 任务场景分类与谱系化设计

在系统级任务场景验证中，场景不是随意编写的“剧情”，而是对系统在未来真实任务中可能遭遇的各类工况、环境与状态的结构化抽象。若场景划分混乱，验证覆盖就会出现盲区：正常工况反复测、边界工况没人测、故障与应急工况靠临时补。因此，本节要解决两个问题：按什么原则把场景分成正常、边界、降级、故障、应急五类，以及如何用谱系化方式把它们组织成可追溯、可覆盖、可复用的场景集合。

一、五类场景的划分原则

五类场景的本质区别不在“严重程度”这一条轴上，而在于系统能力是否完整、任务目标是否保持、触发源来自哪里三个维度的组合。划分时建议遵循以下原则。

原则一：以“能力可用性”为主判据。正常场景下系统全部功能可用，任务目标不变；边界场景下功能仍可用，但某项参数已逼近设计包线；降级场景下部分功能被主动关闭或性能受限，任务目标需调整但仍可完成；故障场景下出现非预期的部件或功能失效；应急场景下故障已威胁任务安全或人员安全，必须执行应急程序。

原则二：触发源决定归类归属。由外部环境或任务输入引起的极端工况（如高低温极限、最大过载）归入边界；由系统内部非预期失效引起的归入故障；由人为或自动保护逻辑主动切换引起的归入降级。同一物理现象可能因触发源不同而分属不同类别，例如“推力下降”若由发动机故障引起属故障场景，若由控制系统主动限推以保护结构则属降级场景。

原则三：目标保持性作为辅助判据。正常与边界场景的任务目标完全保持；降级场景目标可裁剪但主任务仍达成；故障场景目标可能部分丧失；应急场景以“安全返回/安全模式”替代原任务目标。

原则四：可验证性约束。每类场景必须能对应到可观测的判据，例如正常场景判据是“全部性能指标满足要求”，边界场景判据是“在包线边缘仍不触发保护、不越界”，降级场景判据是“降级后剩余功能满足最低任务要求”。无法定义判据的场景不应进入谱系。

二、谱系化组织方式

谱系化不是简单地把场景列成一张清单，而是建立“任务阶段—场景类别—具体场景—验证判据”的四级映射结构，使每个场景都能追溯到任务剖面中的位置，并向下关联到具体验证用例。

组织时可采用“主轴+分支”的方式：以任务阶段（如发射、入轨、在轨运行、返回）为主轴，在每个阶段下按五类场景展开分支。这样既能保证每个阶段都被五类场景覆盖，又能避免场景在阶段之间重复。对于跨阶段的场景（如长时间在轨故障累积），可单独设立“跨阶段场景”分支，并标注其影响的阶段范围。

谱系化还需要编号与追溯。建议采用“阶段码-类别码-序号”的编号规则，例如“ORB-BND-003”表示在轨阶段的第3个边界场景。编号一旦确定不应随意变更，以便验证用例、测试报告和问题单之间建立稳定引用。

此外，谱系应支持覆盖度检查。对每个任务阶段，检查五类场景是否都有实例；对每个关键功能，检查是否在至少一个故障场景和降级场景中被覆盖；对每个安全关键项，检查是否有对应的应急场景。覆盖度不足的分支应补充场景，而不是用“正常场景多测几遍”来替代。

三、谱系化设计的落地要点

在实际项目中，谱系化设计通常从任务剖面出发，先画出阶段划分，再逐阶段填充五类场景。填充时建议采用“先正常、再边界、后降级、再故障、最后应急”的顺序，因为正常场景定义了基准，边界场景定义了包线，降级和故障场景才能在此基础上判断“偏离了多少”。

每个场景应至少包含以下要素：场景编号、所属阶段、场景类别、触发条件、系统初始状态、任务目标、关键参数取值、预期系统响应、验证判据、关联验证用例编号。这些要素不必全部写进一张表，但必须在场景描述中可追溯。

谱系化完成后，应做一次交叉覆盖检查：对每个关键功能，确认它在正常、边界、降级、故障、应急五类中是否都有对应场景；对每个安全关键项，确认应急场景是否覆盖了最坏情况；对每个阶段，确认五类场景是否齐全。若某类场景在某阶段确实不适用（例如发射段不存在“在轨长期降级”），应在谱系中显式标注“不适用”并说明理由，而不是留空。

最后需要强调，谱系化不是一次性工作。随着任务剖面细化、设计变更或验证中发现新问题，场景谱系应同步更新，并保持编号稳定、追溯关系不断裂。只有这样，五类场景才能真正成为系统级验证的“覆盖地图”，而不是一张静态清单。