4、触发条件分析：什么是触发条件？如何从场景中提取触发条件？

好，咱们进入第四讲。前面我们聊了场景是什么，怎么构建场景库。但光有场景还不够，你得知道——到底是什么因素，让一个本来安全的场景，突然变得危险了？

这个「罪魁祸首」，就是触发条件。我个人习惯把它叫做「压垮骆驼的最后一根稻草」。你想想看，一个场景可能跑了上千次都没事，但某个条件一出现，系统就崩了。嗯，这就是我们要找的东西。

4.1 触发条件的定义

触发条件，说白了就是导致系统发生危害行为的具体条件或事件。它可以是环境因素、系统状态、驾驶员行为，或者它们的组合。

在SOTIF标准里，触发条件分为两类：

• 直接触发条件：直接导致危害发生。比如「传感器被强光直射」。
• 间接触发条件：通过影响系统性能，间接导致危害。比如「路面摩擦系数降低，导致制动距离变长」。

我在项目中遇到过一件事：一个L3级自动驾驶系统，在高速隧道场景下测试了上百次都没问题。结果有一次，隧道入口处刚好有一块反光广告牌，阳光角度又特别刁钻——传感器瞬间过曝，车辆直接偏离车道。你看，隧道场景没变，但「阳光+反光牌」这个触发条件，才是真凶。

4.2 触发条件的分类体系

为了系统性地找触发条件，我建议你从三个维度去拆解：

维度	子类	典型例子
环境触发	光照、天气、道路	逆光、暴雨、路面标线磨损
系统触发	传感器、算法、执行器	传感器脏污、模型误检、制动延迟
交互触发	其他交通参与者、自车状态	行人突然冲出、自车轮胎打滑

为什么要这么分？因为不同维度的触发条件，对应的缓解策略完全不同。环境触发靠硬件冗余，系统触发靠算法优化，交互触发靠行为预测。你想想看，如果混为一谈，后面做功能改进时就会抓瞎。

4.3 如何从场景中提取触发条件？

好，到了实操环节。怎么从场景里把触发条件「拎」出来？我总结了四步法：

步骤一：场景分解

先把场景拆成最小单元。比如「夜间城市道路，有行人横穿」这个场景，可以拆成：

• 环境：夜间、路灯照明、干燥路面
• 自车：车速40km/h、近光灯开启
• 目标：行人、横穿方向、步行速度1.2m/s

步骤二：识别潜在危害

问自己一个问题：这个场景下，系统最可能出什么错？

• 传感器没检测到行人？
• 检测到了但分类错误？
• 分类正确但决策太晚？

步骤三：反向推导触发条件

针对每个潜在危害，反向问：什么条件会导致这个危害发生？

举个例子：

• 危害：夜间未检测到行人
• 触发条件：行人穿深色衣服 + 背景是深色墙面 + 路灯照明不足

步骤四：组合与边界测试

单个触发条件往往不够致命，多个条件组合才是杀手。我曾经遇到一个案例：

场景：高速弯道，傍晚时分
单个触发条件A：弯道曲率较大（R=200m）
单个触发条件B：车道线磨损（反光率降低30%）
组合触发条件A+B：车道线检测失效，车辆偏离车道

你看，单独一个条件，系统还能应付。但组合在一起，就突破了系统的能力边界。

4.4 提取触发条件的常用方法

在实际项目中，我常用这几种方法来提取触发条件：

1. 头脑风暴法：组织功能安全、系统、算法、测试工程师一起，对着场景逐项过。嗯，这个方法最原始，但也最有效。
2. 基于经验库：把之前项目、行业报告、公开事故中发现的触发条件整理成库。每次新项目直接查库，能省不少时间。
3. 数据驱动法：用路采数据或仿真数据，跑异常检测算法，自动识别触发条件。这个方法效率高，但需要大量数据支撑。
4. 形式化分析：用STPA（系统理论过程分析）等方法，系统性地推导触发条件。适合复杂系统，但学习成本高。

4.5 触发条件的文档化

提取出来的触发条件，不能只记在脑子里。我建议用统一的模板记录下来：

字段	说明	示例
ID	唯一编号	TC-ENV-001
所属场景	关联的场景ID	SC-URBAN-012
触发条件描述	具体条件	逆光角度在15°-30°之间
触发维度	环境/系统/交互	环境
潜在危害	导致的危害行为	行人检测漏报
严重度	S/E/C等级	S2
发现来源	测试/仿真/事故	路测数据

为什么要文档化？因为触发条件会随着系统迭代而变化。今天发现的触发条件，明天可能因为算法升级就不存在了。但新的触发条件又会出现。所以，这是一个持续更新的活。

4.6 小结

触发条件分析，是SOTIF场景探索中最核心的一环。没有它，你就是在黑暗中乱撞。记住三点：

• 触发条件是场景中的「引爆点」，不是场景本身
• 从三个维度去拆解：环境、系统、交互
• 组合条件比单一条件更危险，别忽略它们

下一讲，我们会聊聊如何用这些触发条件来设计测试用例。到时候我会分享一个我踩过的坑——因为漏了一个触发条件，整个测试方案差点重做。嗯，到时候细说。