4. SOTIF开发流程
场景参数化设计，说白了就是把测试场景里的可变因素提炼出来，变成一个个可以调节的旋钮。你想想看，如果每个场景都手写死数据，那场景库建到后面就是个灾难——改一个路口逻辑，几十个场景都得跟着调。
我个人习惯，拿到一个功能需求后，第一件事不是写场景，而是先列参数。把能变的、该变的、可能出问题的变量全列出来。这一步做扎实了，后面的工作才有根基。
4.1 参数空间定义
参数空间，就是所有可变参数的取值范围构成的集合。我见过不少团队，参数定义得特别随意——车速范围设个0到200 km/h，看着挺全，实际上一大半取值根本用不上。
定义参数空间，我建议按三个维度来梳理：
| 维度 | 说明 | 典型参数举例 |
|---|---|---|
| 环境参数 | 车辆运行的外部条件 | 光照强度、路面摩擦系数、天气类型、温度 |
| 自车参数 | 被测车辆自身状态 | 初始车速、加速度、转向角、传感器配置 |
| 交互参数 | 与其它交通参与者的关系 | 目标车距离、相对速度、切入角度、行人意图 |
每个参数都要明确它的类型和量纲。比如车速是连续型浮点数，单位m/s；天气是枚举型，取值{晴, 雨, 雪, 雾}。我在项目中遇到过有人把枚举型参数当连续型处理，结果生成了一堆不可能出现的组合——比如“晴天+路面结冰”，这种场景跑出来也没意义。
4.2 参数边界与组合
参数边界，就是每个参数的极限值。为什么边界重要？因为系统往往在边界处出问题。我记得有一次做AEB（自动紧急制动）测试，参数空间里目标车距离设了5m到100m，结果所有场景都跑在中间段。后来我专门补了一组边界场景——目标车距离2.5m、3m、4m——果然复现了一个传感器延迟导致的漏报问题。
边界值选取有个通用原则：
- 物理边界：车辆能达到的极限，比如最大减速度、最大转向角
- 法规边界：标准规定的阈值，比如Euro NCAP的测试速度点
- 设计边界：系统设计文档里写的正常工作范围
- 经验边界：你从实车测试中发现的敏感点
参数组合，则是把多个参数的取值排列组合起来。这里有个坑——组合爆炸。假设你有10个参数，每个取5个值，组合数就是5的10次方，接近一千万。跑不完，根本跑不完。
我常用的组合策略有三种：
- 全因子组合：参数少（≤4个）时用，覆盖所有组合
- 单因子轮换：固定其他参数，每次只变一个，适合找单个参数的影响
- 正交实验设计：用正交表选取代表性组合，用最少场景覆盖最大参数空间
核心原则：参数组合不是越多越好，而是越精越好。用20%的场景覆盖80%的参数空间，剩下的边界场景单独补。这才是工程上可行的做法。
4.3 参数敏感性分析
参数敏感性分析，就是搞清楚哪个参数对测试结果影响最大。说白了，帮你找到“哪个旋钮拧一下，系统反应最剧烈”。
我一般用两种方法：
| 方法 | 原理 | 适用场景 |
|---|---|---|
| 局部敏感性分析 | 每次只变一个参数，看输出变化 | 参数少、线性关系强时 |
| 全局敏感性分析 | 所有参数同时变化，用统计方法评估贡献度 | 参数多、存在交互效应时 |
局部敏感性分析简单直观，但容易漏掉参数间的交互效应。全局敏感性分析更准确，但计算量大。我个人的做法是：先用局部分析快速筛选出敏感参数，再用全局分析对敏感参数做精细评估。
举个例子，做自适应巡航（ACC）的跟车场景测试。我列了5个参数：前车初始速度、前车减速度、自车初始速度、自车跟车时距、路面附着系数。局部分析跑下来，发现前车减速度和跟车时距这两个参数对碰撞时间（TTC）影响最大。然后我用全局分析进一步看，发现这两个参数之间还有交互——低附着系数下，跟车时距的影响会被放大。
做完敏感性分析后，我会把参数分成三类：
- 高敏感参数：重点覆盖，边界值、中间值、典型值都要测
- 中敏感参数：适度覆盖，取几个代表性值即可
- 低敏感参数：固定为典型值，不需要大量变化
这样分类之后，场景库的构建效率能提升一大截。你想想看，把精力花在刀刃上，比盲目堆场景有用得多。
嗯，这里要注意一点。敏感性分析不是一次性工作。随着场景库的迭代，参数的重要性排序可能会变。我建议每迭代两到三个版本，重新做一次敏感性分析，看看有没有新的敏感参数冒出来。
最后说一句，参数化设计做得好不好，直接决定了场景库的扩展性和复用性。你想想看，如果参数定义得合理，新场景只需要改几个参数值就能生成，根本不用从头写。这才是场景库该有的样子。