2. 自动驾驶场景定义:场景、情景、场景要素

各位同学,咱们今天聊点实在的。做SOTIF分析,第一步就是搞清楚:你到底在分析什么场景?

我见过不少团队,上来就对着ODD列表猛写测试用例,结果写到一半发现——场景定义没对齐,A工程师说的“高速汇入”和B工程师说的根本不是一回事。嗯,这种坑我踩过,所以今天咱们把基础打牢。

2.1 场景与情景:别搞混了

先问个问题:场景和情景,是一回事吗?

我个人习惯这样区分——情景是快照,场景是故事。

  • 情景(Scenario):某一时刻的系统状态快照。比如“自车车速80km/h,前车距离50米,车道线清晰,天气晴朗”。
  • 场景(Scene):一段连续的时间序列,由多个情景串联而成。比如“自车从80km/h巡航,到前车切入,再到自车减速跟车”。

一句话记住:情景是照片,场景是电影。

在SOTIF分析中,我们关注的是场景。因为功能安全失效往往不是瞬间发生的,而是随着时间推移、环境变化逐步暴露的。我记得有个项目,客户抱怨AEB在雨天误触发。单看某个时刻的情景——自车正常行驶、前车距离安全——完全没问题。但把时间拉长,发现是雨刷摆动频率和摄像头帧率产生了某种耦合,导致连续几帧的测距跳变。这就是场景分析的价值。

2.2 场景四要素:道路、交通、环境、自车

做场景定义,我习惯用“四要素法”来拆解。说白了,就是回答四个问题:

  1. 在哪开?(道路)
  2. 周围有什么?(交通)
  3. 天气怎么样?(环境)
  4. 车自己在干嘛?(自车)

这四个要素缺一不可。你想想看,如果只定义道路和自车,忽略了交通参与者,那场景就是残缺的。我曾经评审过一个场景库,里面全是“直道-自车60km/h-晴天”这种组合,结果一上路,各种corner case全没覆盖到。

2.2.1 道路要素

道路是场景的“舞台”。我一般把它分成三个层级:

层级 内容 举例
道路类型 高速公路、城市道路、乡村道路、停车场 高速:车道数、是否有应急车道
道路几何 直道、弯道、坡度、曲率 弯道:半径R=200m,坡度5%
道路设施 车道线、护栏、交通标志、信号灯 车道线:虚线/实线/磨损程度

避坑指南:我曾经在定义“弯道”场景时,只写了“弯道半径<500m”。结果测试团队找了一段半径480m的弯道,但路面有积水、车道线模糊,系统直接退出了。后来我学乖了——道路要素必须组合使用,单一参数定义场景是危险的。

2.2.2 交通要素

交通要素是场景的“演员”。包括:

  • 其他车辆:轿车、卡车、公交车、摩托车、自行车
  • 行人:成人、儿童、推婴儿车、打伞、奔跑
  • 动物:宠物、野生动物(这个在国内城市较少,但郊区项目要注意)
  • 静态障碍物:锥桶、施工区域、路边停靠车辆

这里有个关键点:交通参与者的行为意图。同样是行人,站在路边和突然横穿马路,场景风险天差地别。我建议在定义交通要素时,加上“行为状态”维度:静止、匀速、加速、减速、切入、切出、变道、转弯。

2.2.3 环境要素

环境是场景的“灯光和特效”。它直接影响传感器的感知质量。

环境维度 参数示例 对SOTIF的影响
光照 白天、黄昏、夜晚、逆光、隧道出入口 摄像头动态范围不足,逆光导致目标丢失
天气 晴天、阴天、雨、雪、雾、霾 激光雷达在雨雾中衰减,摄像头在雪天对比度下降
温度 -20°C ~ 60°C 极端温度影响传感器性能,甚至导致系统降级

注意:环境要素不是独立存在的。比如“夜晚+雨天”的组合,对视觉感知的挑战是指数级上升的。我见过一个案例,系统在“白天小雨”场景下表现正常,但到了“夜晚中雨”,AEB误触发率直接翻了5倍。所以,环境要素一定要做组合分析。

2.2.4 自车要素

自车是场景的“主角”。包括:

  • 运动状态:车速、加速度、横摆角速度、方向盘转角
  • 系统状态:ADAS功能开启/关闭、系统降级模式、传感器健康状态
  • 车辆参数:轴距、轮距、制动性能、转向响应

这里我想强调一点:自车状态不是静态的。同一个场景,自车以60km/h通过和以100km/h通过,系统的响应和安全边界完全不同。所以定义场景时,自车要素要给出一个范围,而不是一个固定值。

2.3 场景要素的组合与分层

四要素不是平铺直叙的,它们之间有层级关系。我习惯用下面这张图来理解:

场景四要素层级关系 场景 (Scene) 情景序列 (Scenario Sequence) 道路 交通 环境 自车 道路参数 类型 / 几何 / 设施 曲率 / 坡度 / 车道数 交通参数 类型 / 数量 / 行为 速度 / 意图 / 交互 环境参数 光照 / 天气 / 温度 能见度 / 路面附着 自车参数 车速 / 系统状态 传感器健康 / 功能模式 场景 = 情景序列 = f(道路, 交通, 环境, 自车) 每个要素由一组参数描述,参数组合决定场景的复杂度

从这张图可以看得很清楚:场景是由一系列情景组成的,每个情景又是四要素的特定取值组合。做SOTIF分析时,我们不是分析单个情景,而是分析情景序列中可能出现的功能不足。

2.4 场景定义的实践要点

最后,分享几个我在项目中总结的经验:

场景定义三原则:

  1. 可测量:每个要素参数都要有明确的量化方式。别写“车速较快”,要写“车速80-100km/h”。
  2. 可复现:场景描述要足够精确,让不同团队能复现出相同的测试条件。
  3. 可组合:要素之间要支持自由组合,方便生成corner case。

我的习惯:每次定义新场景,我都会先画一个四要素的表格,把每个要素的关键参数列出来。然后问自己三个问题:

  • 这个场景的“危险时刻”是什么?
  • 哪个要素的变化触发了危险?
  • 如果改变其中一个要素,场景风险会怎么变化?

这三个问题能帮你快速聚焦到SOTIF分析的核心。

曾经踩过的坑:有一次我们定义“城市路口左转”场景,只考虑了“自车-对向直行车辆”的交互。结果实车测试时,系统对“对向车辆+右侧非机动车”的组合完全没反应。从那以后,我要求场景定义必须包含所有相关交通参与者,一个都不能少。