3. 场景测试基础

在自动驾驶安全验证中，“场景”不是一段简单的路测录像，也不是一句“前车急刹”的口头描述，而是一个可被工程化表达、可复现、可参数化、可判定的测试基本单元。SOTIF（ISO 21448）关注的是预期功能安全，即系统在没有电子电气故障的前提下，仍可能因性能局限、场景理解不足或人机交互不充分而产生危害行为。因此，场景测试成为 SOTIF 闭环工程的核心输入与验证载体。

一、场景定义：从现实世界到可测对象

场景定义通常包含三层含义：静态环境（道路几何、车道线、交通标志、天气光照）、动态实体（自车、他车、行人、骑行者及其运动状态）、任务与事件（自车意图、触发条件、预期响应）。一个完整的场景描述应能回答：在哪里、什么时候、谁参与、发生了什么、系统应如何表现。

工程上常用“场景 = 初始状态 + 事件序列 + 评价条件”来表达。例如：

场景ID: SC-URBAN-014
初始状态: 双向四车道城市道路，限速50km/h，晴天，自车车速40km/h
事件序列: 右前方公交车靠站停车 → 行人从公交车前横穿 → 自车需制动避让
评价条件: 不碰撞、不越线、减速度≤4m/s²、TTC≥1.5s

这种结构化表达使场景从“故事”变为“测试用例”，便于自动化生成、执行和判定。

二、场景分层：从功能到具体参数

场景分层是管理复杂度的关键。业界常采用三层结构：功能场景、逻辑场景、具体场景。功能场景用自然语言描述抽象行为，如“车辆在路口左转时与对向直行车辆冲突”；逻辑场景引入参数范围，如自车速度[20,60]km/h、对向车速度[30,70]km/h、距离[10,80]m；具体场景则固定参数取值，形成可执行测试用例。

分层的好处在于：功能场景用于需求分析与危害识别，逻辑场景用于参数空间探索与覆盖率评估，具体场景用于仿真、台架和实车测试执行。三者形成“抽象—参数—实例”的映射链。

三、场景要素：构建场景的“原子”

场景要素可归纳为五类：道路要素（车道数、曲率、坡度、路口类型）、交通设施（信号灯、标志、标线）、动态对象（车辆、行人、动物、障碍物）、环境条件（光照、天气、路面附着）、自车状态（速度、加速度、转向、传感器状态）。这些要素通过参数化组合，可生成海量测试场景。

四、场景与 SOTIF 的关系

SOTIF 的核心问题是“未知不安全场景”导致的危害。场景测试正是发现和覆盖这些场景的手段。SOTIF 将危害行为分为已知安全、已知不安全、未知不安全三类，场景测试的目标是不断将“未知不安全”转化为“已知不安全”，再通过设计改进将其转化为“已知安全”。

因此，场景与 SOTIF 的关系可概括为：场景是 SOTIF 分析的输入，也是 SOTIF 验证的输出。分析阶段用场景识别危害，验证阶段用场景证明安全。没有场景，SOTIF 就失去了可操作的对象。

五、场景测试在自动驾驶验证中的定位

自动驾驶验证体系通常包括：仿真测试、台架测试、封闭场地测试、公开道路测试。场景测试贯穿其中，是连接各层验证的“通用语言”。仿真可大规模跑逻辑场景，台架可注入传感器信号，场地可复现具体场景，路测可采集新场景反哺场景库。

验证层级	场景类型	主要目的	典型工具
仿真测试	逻辑场景/具体场景	快速覆盖参数空间	CARLA、Prescan、VTD
台架测试	具体场景	传感器与算法闭环	dSPACE、NI
封闭场地	具体场景	实车功能验证	假人、假车、V2X
公开道路	自然场景	发现未知场景	数据采集车、影子模式

场景测试的定位不是替代实车路测，而是以更低成本、更高效率、更可控的方式，把安全验证从“里程驱动”转向“场景驱动”。在 SOTIF 闭环中，场景库的覆盖度、参数边界和通过率，直接决定安全论证的可信度。

六、常见误区与复盘

误区一：把场景等同于路测片段。路测片段只是原始数据，未经参数化和抽象，难以复用和扩展。

误区二：只关注具体场景，忽略逻辑场景。具体场景通过不代表参数空间安全，必须用逻辑场景探索边界。

误区三：场景库只增不减，缺乏优先级。应按 SOTIF 危害分析结果，优先覆盖高风险、高暴露、高严重度场景。

误区四：仿真通过即认为安全。仿真模型保真度有限，必须与台架、场地、路测形成证据链。

复盘时建议检查：场景是否可复现？参数是否可追溯？评价指标是否量化？场景与危害是否对应？只有形成“场景定义—分层—要素—测试—反馈”的闭环，场景测试才能真正支撑 SOTIF 安全论证。

综上，场景测试基础是 SOTIF 闭环工程的起点。只有把场景定义清楚、分层合理、要素完整，并明确其在验证体系中的定位，才能让后续的测试设计、执行和评估有据可依。场景不是测试的附属品，而是安全论证的核心资产。