1、场景库概述:预期功能安全(SOTIF)背景、场景定义与分类、场景库在开发中的价值

1.1 为什么我们需要SOTIF?

做功能安全的朋友都知道ISO 26262,它主要管的是系统故障和随机硬件失效。但干过实车测试的工程师都明白——很多时候车出问题,不是硬件坏了,也不是软件写崩了,而是系统遇到了它没见过的场景

我2019年跟一个L4项目时,遇到过一件特别头疼的事。一辆测试车在高速上正常行驶,前方有个大货车掉下来一块篷布。视觉系统识别成「可通行区域」,直接加速冲过去了。你说传感器坏了吗?没有。算法错了吗?从训练数据看也没错。这就是典型的预期功能安全(SOTIF)问题——系统在预期功能范围内,因为性能局限或环境干扰,产生了危害。

ISO 21448(SOTIF标准)就是专门管这个的。它关注的是:功能本身没问题,但场景超出了系统的「认知边界」

核心定义:预期功能安全(SOTIF)是指不存在因预期功能的功能不足或可合理预见的人员误用而导致的不合理风险。

说白了,就是你的感知、决策、执行系统,在它该干活的时候,能不能在所有合理可预见的场景下都干好活。

1.2 场景到底是什么?

场景这个词,圈里人天天挂在嘴边。但你真的问「场景怎么定义」,十个人能给你八个答案。我个人习惯用这个三层结构来理解:

  • 场景(Scenario):一段连续的时间-空间描述,包含静态环境、动态元素、自车行为、天气光照等所有因素。
  • 情景(Situation):某个时间切片下的快照。比如「此刻自车速度60km/h,前方50米有静止车辆」。
  • 用例(Use Case):从功能视角看,系统要完成什么任务。比如「自动变道」、「十字路口左转」。

你想想看,这三个概念经常被混用。我在项目评审会上就见过,测试工程师说「我跑了1000个场景」,结果一看全是同一段路的不同光照条件——这其实只能算一个场景的多个情景。

1.3 场景怎么分类?

分类方式很多,我按工程落地最常用的维度来梳理:

分类维度 类型 举例
按抽象层级 功能场景 / 逻辑场景 / 具体场景 「前车减速」→「前车以2m/s²减速」→「前车在50米处以2m/s²减速至20km/h」
按危险程度 正常场景 / 边缘场景 / 危险场景 直行通过路口 / 行人突然横穿 / 儿童从停车间隙冲出
按要素来源 真实采集场景 / 仿真生成场景 / 组合衍生场景 路采数据片段 / 参数化随机生成 / 两个场景拼接
按触发条件 感知受限场景 / 决策模糊场景 / 执行极限场景 逆光、雨雾 / 多目标博弈 / 湿滑路面制动

嗯,这里要注意——分类的目的是为了覆盖,不是为了分类本身。我见过有些团队把场景分了十几类,结果每类就几个样本,反而漏掉了最关键的corner case。

1.4 场景库在开发中的价值

场景库不是一堆测试用例的集合。它应该是整个SOTIF开发流程的「数据底座」。我画了一张图来说明它的位置:

场景库在SOTIF开发中的核心位置 数据来源 真实路采 | 仿真生成 | 事故数据库 | 标准法规 | 专家经验 场景库(Scenario Library) 功能场景 → 逻辑场景 → 具体场景 覆盖度分析 | 参数化 | 标注 | 版本管理 应用输出 SOTIF危害分析与风险评估 功能不足识别与触发条件分析 验证与确认(V&V)用例生成 仿真测试场景注入 实车测试场景编排 安全论证与合规证据

从这张图你能看到,场景库不是孤立的。它向上承接各种数据源,向下支撑所有SOTIF活动。我个人的经验是:场景库的质量,直接决定了SOTIF开发的效率

实战建议:刚开始建场景库时,别追求大而全。先聚焦你最核心的ODD(运行设计域)内的典型场景,把覆盖度做到80%,剩下的20%边缘场景通过仿真和路采逐步补齐。我曾经见过一个团队,花了一年时间建了10万个场景,结果80%是重复的——这就是典型的「为了数量而数量」。

1.5 场景库的核心能力要求

一个能用的场景库,至少得具备这五个能力:

  1. 可扩展性:新场景能方便地加入,不影响已有结构。我建议用标签体系而非固定分类。
  2. 可参数化:同一个逻辑场景,能通过参数变化生成大量具体场景。比如「前车切入」这个场景,速度、距离、角度都可以参数化。
  3. 可追溯:每个场景都能追溯到来源——是路采的?仿真的?还是标准里来的?这在安全论证时特别重要。
  4. 可度量:能算覆盖度。哪些场景类型覆盖够了,哪些还有缺口,要能量化。
  5. 可复用:不同项目、不同功能之间能共享场景。别每个项目从零开始建。

避坑指南:我曾经在一个项目中,场景库用Excel管理,结果版本一多就乱套了。后来换成了基于数据库的场景管理平台,配合Git做版本控制,才把这个问题解决。场景库的版本管理,比你想象的重要得多——尤其是当你要用场景库做安全论证时,监管机构会问「你用的到底是哪个版本的场景库」。

1.6 场景库与SOTIF开发流程的关系

ISO 21448里有个核心概念叫「功能不足的识别与触发条件分析」。说白了就是:你得知道你的系统在什么场景下会「犯傻」

场景库在这里扮演的角色是:

  • 在HARA阶段:提供场景素材,帮助识别哪些场景可能触发危害。
  • 在功能不足分析阶段:用场景库里的边缘场景去「拷问」系统,看它在哪些场景下表现不佳。
  • 在V&V阶段:从场景库里抽取测试用例,进行仿真和实车验证。
  • 在安全论证阶段:用场景库的覆盖度数据,证明系统在目标ODD内已经充分验证。

我记得有一次做安全评审,评审专家问:「你们怎么证明系统在雨雾天气下是安全的?」我们直接把场景库里雨雾场景的覆盖度报告、测试通过率、以及未覆盖场景的风险评估摆出来——这就是场景库的价值体现。

好了,这一章我们先把场景库的「是什么」和「为什么」讲清楚。下一章我会详细讲场景库怎么建——从数据采集到场景提取,再到参数化建模,每一步都有坑,我会把踩过的坑都告诉你。

本章要点回顾:

  • SOTIF解决的是「功能正常但场景超出认知」的问题
  • 场景 = 功能场景 → 逻辑场景 → 具体场景的三层抽象
  • 场景库是SOTIF开发的「数据底座」,支撑HARA、功能不足分析、V&V、安全论证
  • 好的场景库要具备:可扩展、可参数化、可追溯、可度量、可复用

公众号:蓝海资料掘金营,微信deep3321