2. SOTIF基础概念
各位同学，今天我们正式进入场景分析的核心地带。说实话，场景这个词在SOTIF里被反复提及，但真正能把它讲清楚的人不多。我刚开始接触预期功能安全时，也一度被各种场景术语绕晕——功能场景、逻辑场景、具体场景，到底有什么区别？
后来在做一个L3级高速公路领航项目时，我花了整整两周时间梳理场景库，才真正摸透了这套理论。今天我就把当时的理解，结合项目中的实际体会，跟大家掰开揉碎讲一讲。
场景的定义：不只是“路况”那么简单
先问大家一个问题：什么是场景？
很多人第一反应是“道路环境+交通参与者”。嗯，这个理解没错，但不够完整。在SOTIF语境下，场景的定义要严谨得多。
场景（Scenario）：描述一段连续时间内，自车、交通参与者、道路结构、环境条件、天气光照等所有相关元素的静态与动态状态，以及它们之间的交互关系。
说白了，场景就是一段“故事”——有开头、有过程、有结尾。它不只是某个瞬间的快照，而是一个时间序列。
举个例子：
- 快照：前方50米有一辆静止的白色轿车，天气晴朗。
- 场景：自车以80km/h行驶在高速最左侧车道，前方50米处一辆白色轿车因故障停在车道内，双闪开启，后方车辆开始变道避让，天气晴朗，路面干燥，自车驾驶员注意力分散。
看出区别了吗？场景包含了时间维度和交互关系。我在项目中吃过这个亏——早期我们只记录了“前方有静止车辆”这个快照，结果测试时发现，同样的静止车辆，在不同车速、不同驾驶员状态下的系统表现完全不同。
场景三要素：场景、事件、行为
场景理论里，有三个核心概念必须分清：场景（Scenario）、事件（Event）、行为（Behavior）。它们之间的关系，我习惯用一个三层结构来理解。
我来逐一解释：
| 要素 | 定义 | 举例 |
|---|---|---|
| 场景 | 整体环境与状态的描述，包含所有静态和动态元素 | 高速路段，三车道，车流量中等，雨天，自车开启ACC |
| 事件 | 场景中发生的某个具体变化或触发条件 | 相邻车道车辆突然切入自车前方 |
| 行为 | 自车或他车对事件的响应动作 | 自车减速、他车继续切入、后车鸣笛 |
我的经验：在构建场景库时，我建议先把“事件”列清楚。事件是场景的“触发器”，抓住了事件，行为和场景自然就串起来了。我曾经在一个项目中，团队花了大量时间描述场景细节，结果发现事件定义模糊，导致后续测试用例无法复用。
场景分类：功能场景、逻辑场景、具体场景
这部分是场景理论的重头戏。ISO 21448里把场景分为三个层次，我当年第一次看到时也觉得抽象。后来在实际项目中，我用一个“从抽象到具体”的漏斗模型来理解，一下子就通了。
功能场景：用自然语言讲故事
功能场景是最上层的抽象描述。说白了，就是用大白话把场景讲清楚。它不涉及具体参数，只描述“发生了什么”。
举个例子：
功能场景：自车在高速公路上行驶，前方有一辆慢速行驶的卡车，
自车试图向左变道超车，但左侧车道后方有快速接近的车辆。你看，这里没有车速值、没有距离值、没有车道宽度——只有语义描述。功能场景的作用是让所有利益相关方（工程师、测试员、项目经理、安全专家）都能理解同一个故事。
注意：功能场景虽然简单，但它是整个场景分析的起点。我见过不少团队跳过这一步，直接进入逻辑场景，结果导致参数范围定义不合理，回头又要返工。功能场景的价值在于“对齐认知”——确保大家对同一个场景的理解没有偏差。
逻辑场景：给参数加上范围
逻辑场景是在功能场景的基础上，把关键参数提取出来，并定义它们的取值范围。这一步开始进入工程化阶段。
还是刚才那个例子：
逻辑场景参数空间：
- 自车速度：80~120 km/h
- 卡车速度：40~60 km/h
- 自车与卡车初始距离：50~150 m
- 左侧车道后方车辆速度：100~140 km/h
- 左侧车道后方车辆距离：30~100 m
- 车道宽度：3.5~3.75 m
- 路面摩擦系数：0.5~0.8
- 天气：晴天/小雨逻辑场景的核心是“参数空间”——每个参数都有一个范围，而不是一个固定值。这样做的目的是覆盖尽可能多的真实情况。
我个人习惯在逻辑场景阶段做两件事：
- 参数敏感性分析：哪些参数对系统行为影响最大？比如车速和距离，通常比车道宽度更敏感。
- 边界值识别：参数范围的边界往往是危险区域。比如自车速度120km/h、距离30m时，系统可能来不及响应。
具体场景：确定每一个参数值
具体场景是逻辑场景的一个实例化——从参数空间中选取一组具体的值，形成一个可执行的测试用例。
具体场景实例：
- 自车速度：100 km/h
- 卡车速度：50 km/h
- 自车与卡车初始距离：80 m
- 左侧车道后方车辆速度：120 km/h
- 左侧车道后方车辆距离：50 m
- 车道宽度：3.5 m
- 路面摩擦系数：0.7
- 天气：晴天一个逻辑场景可以衍生出成百上千个具体场景。这就是为什么场景库的规模会迅速膨胀——你想想看，每个参数取3个值（低、中、高），5个参数就是3⁵=243个具体场景。
避坑指南：我曾经在一个项目中，团队一口气生成了5000多个具体场景，结果发现大部分场景是冗余的——它们覆盖的是参数空间的中间区域，而真正危险的边界场景反而被遗漏了。后来我们改用“组合覆盖设计方法”，用更少的场景覆盖了更多的边界条件。这个方法论后面章节会详细讲。
三类场景的对比总结
| 维度 | 功能场景 | 逻辑场景 | 具体场景 |
|---|---|---|---|
| 抽象程度 | 高 | 中 | 低 |
| 描述方式 | 自然语言 | 参数+范围 | 参数+确定值 |
| 主要用途 | 需求分析、沟通对齐 | 测试设计、参数探索 | 仿真执行、实车测试 |
| 数量规模 | 几十个 | 几百个 | 成千上万个 |
| 修改成本 | 低 | 中 | 高 |
嗯，到这里，场景理论的基础框架就搭起来了。你可能会问：知道了这些分类，然后呢？
其实，这三类场景对应着SOTIF开发流程中的不同阶段：功能场景用于危害分析和风险评估，逻辑场景用于安全目标定义和测试策略设计，具体场景用于仿真验证和实车测试。它们是层层递进的关系，缺一不可。
我记得有一次评审会上，一个同事拿着逻辑场景的参数范围问我：“这个范围是怎么定的？”我反问他：“你的功能场景里，卡车是‘慢速行驶’，那‘慢速’到底是多少？”他愣了一下，回去重新梳理了功能场景的语义描述。你看，这就是三层分类的价值——它逼着我们把模糊的描述变成可量化的工程参数。