📚 课程目录第3章 SOTIF核心术语

3. SOTIF核心术语

场景分类这件事，很多团队一开始都容易搞混。我记得刚带项目那会儿，大家开会说「场景」这个词，结果每个人脑子里想的完全不是一回事。有人拿的是需求文档里的功能描述，有人拿的是测试用例，还有人直接甩过来一段仿真波形。嗯，这就是分类没对齐的典型症状。

今天我们就来把这三个层级彻底理清楚。说白了，就是回答三个问题：系统该干什么？可能遇到什么情况？具体怎么测？

3.1 三个层级，各司其职

先看一张总览图，我习惯把它叫做「场景金字塔」。

这张图我每次培训都会放。你看，从上到下是逐步具体化的过程。功能场景描述「意图」，逻辑场景描述「可能性」，具体场景描述「可执行」。三者缺一不可。

3.2 功能场景：一切从需求出发

功能场景是场景库的「根」。它直接来自系统需求、法规标准或者用户故事。我个人习惯在项目启动阶段，先拉一个功能场景清单，不纠结细节，只回答：系统到底要处理哪些事？

来源	示例	特点
系统需求	ACC 应能跟随前车至停车	描述能力边界
法规标准	Euro NCAP AEB CCRs 测试规程	强制覆盖
用户场景	车辆在高速弯道中遇到切入车辆	真实驾驶痛点
事故复现	某起追尾事故的天气与道路条件	边缘案例挖掘

我的习惯：功能场景用一句话描述，不要带参数。比如「AEB 在十字路口对横穿行人制动」就是一个合格的功能场景。一旦开始写「速度 30 km/h」，你就跳到逻辑场景了。

3.3 逻辑场景：参数空间的「棋盘」

逻辑场景是功能场景的「展开」。说白了，就是把功能场景里的每个要素，拆成可变的参数和取值范围。我在项目中遇到过最典型的错误，就是逻辑场景的参数范围定得太窄，导致测试覆盖严重不足。

举个例子，功能场景「AEB 对前方静止车辆制动」，它的逻辑场景参数空间可能是这样的：

参数	最小值	最大值	步长/离散值	备注
自车速度	10 km/h	80 km/h	10 km/h	覆盖城市与郊区
目标车状态	静止	静止	—	固定值
TTC 触发阈值	1.0 s	4.0 s	0.5 s	系统设计参数
路面附着系数	0.3	1.0	0.1	低附到高附
光照条件	白天	夜晚	白天/黄昏/夜晚	传感器敏感

避坑指南：我曾经因为逻辑场景的参数步长设得太大（比如速度步长 20 km/h），漏掉了一个在 35 km/h 附近才触发的控制振荡问题。后来我学乖了：关键参数先用粗步长扫一遍，发现问题区间再加密。

3.4 具体场景：可执行的「测试用例」

具体场景就是逻辑场景的一次「实例化」。从参数空间里挑一组具体的值，加上初始状态、环境配置、预期行为，就构成了一个可执行的仿真测试用例。

我一般用这样的模板来定义具体场景：

场景ID: SC_AEB_CCRs_001
所属功能场景: AEB 对前方静止车辆制动
所属逻辑场景: LS_AEB_CCRs_v1.0

参数定值:
  - 自车速度: 50 km/h
  - 目标车速度: 0 km/h (静止)
  - TTC 触发阈值: 2.0 s
  - 路面附着系数: 0.85
  - 光照: 白天

初始状态:
  - 自车位于车道中心，距目标车 100 m
  - 目标车完全静止，位于同一车道
  - 天气晴朗，能见度良好

预期行为:
  - 系统在 TTC ≤ 2.0 s 时发出预警
  - 系统在 TTC ≤ 1.2 s 时主动制动
  - 车辆在碰撞前完全停止，或碰撞速度 ≤ 5 km/h

通过标准:
  - 制动减速度 ≥ 4 m/s²
  - 无错误报警
  - 无系统退出

你看，具体场景把逻辑场景里的「范围」变成了「定值」。一个逻辑场景可以衍生出几十甚至上百个具体场景，取决于你选择的参数组合。

3.5 三层之间的转化方法

转化不是自动的，需要人工介入和工具辅助。我总结了一套「三步转化法」：

功能 → 逻辑：参数化
- 识别功能场景中的可变要素
- 为每个要素定义取值范围和步长
- 建立参数之间的约束关系（比如高速时转向角不能太大）
逻辑 → 具体：采样
- 选择采样策略：全因子、正交、边界值、随机
- 生成参数组合矩阵
- 补充环境与初始状态信息
具体 → 可执行：映射
- 将具体场景映射到仿真平台的数据格式
- 配置传感器模型、动力学模型、道路网络
- 编写自动化执行脚本

关键认知：三层结构不是线性流水线，而是迭代的。你在具体场景执行中发现了问题，可能要回溯修改逻辑场景的参数范围，甚至重新审视功能场景的定义。我见过最好的场景库，都是经过 3-4 轮迭代才稳定下来的。

3.6 一个完整的转化案例

拿「LKA 车道保持辅助」来走一遍完整流程：

层级	内容
功能场景	LKA 应在车辆无意识偏离车道时施加纠正力矩
逻辑场景	车速 [30, 120] km/h，偏离角 [0.5°, 5°]，曲率半径 [200, 1000] m，路面类型 {干燥, 湿滑, 积雪}
具体场景 1	车速 80 km/h，偏离角 2°，曲率半径 500 m，干燥路面
具体场景 2	车速 60 km/h，偏离角 4°，曲率半径 300 m，湿滑路面
具体场景 3	车速 100 km/h，偏离角 1°，曲率半径 800 m，积雪路面

嗯，这里要注意：具体场景的数量不是越多越好。我见过有人把一个逻辑场景展开成 5000 个具体场景，结果 80% 都是冗余的。我的建议是先用边界值 + 正交表生成 20-30 个核心场景，跑完一轮再决定要不要扩展。

效率技巧：逻辑场景的参数空间可以用「参数依赖矩阵」来管理。比如车速和曲率半径是强相关的——高速下曲率半径不能太小。把这些约束提前写进逻辑场景定义里，生成具体场景时就能自动过滤掉无效组合。

最后说一句：场景分类体系不是写文档用的，是指导测试设计的。你每次新建一个场景，先问自己：它属于哪一层？上一层是什么？下一层怎么展开？想清楚这三个问题，你的场景库就不会乱。