简介：面向智能网联汽车功能安全从业者、系统与软件工程师及高校相关专业学习者，这份资料提供预期功能安全（SOTIF）领域两份核心标准的中文文本，即国际标准 ISO 21448 与国家标准 GB/T 43267，帮助读者系统理解在无实际故障情况下识别、评估并缓解潜在危险的方法论。压缩包共 1 个 PDF 文件，约 40.15MB，内容为完整标准正文，涵盖规范定义与设计、危害识别与评估、潜在功能不足及触发条件分析、修改功能以解决 SOTIF 相关风险、验证与确认策略等章节，并附术语定义、工作成果清单与组织管理要求，可直接用于标准研读、流程落地与合规对照。目前已有 747 人学习下载，适合需要建立 SOTIF 全生命周期流程认知、对照国内外标准差异或开展跨学科安全协作的读者查阅参考。

1. 拿到这份 SOTIF 中文版，先搞清楚它能替你挡掉哪类锅

做 L2 以上辅助驾驶的同行大概都遇到过这种场面：系统没报任何故障码，传感器、执行器全在正常工作，但车就是做出了一个让人后背发凉的动作——比如把隧道口的白色货车当成天空、把匝道口的锥桶当成可通行区域。这类问题拿 GB/T 34590 那套功能安全的思路去查，查到最后往往是一句“无失效”，然后卡死。预期功能安全（SOTIF）要处理的恰恰就是这块：没有故障，但功能规范定义不足或性能局限被场景触发后产生的危害。这份 GB/T 3267 征求意见稿中文版，就是把这套逻辑从术语、危害识别、触发条件分析一路铺到验证确认和运行阶段监控的完整落地框架，适合正在搭 SOTIF 流程的安全工程师、系统工程师和做 ADAS 功能定义的团队拿来当工作底稿，而不是当科普读物翻。

2. 先分清 SOTIF 和功能安全的边界：别把两类问题混进一个 HARA

很多人第一次接触这份标准，最容易翻车的地方不是看不懂条款，而是把 SOTIF 问题和功能安全问题塞进同一张危害分析表里，结果分析做到一半发现根本对不上。这份标准在引言和附录 A.2 里花了相当篇幅讲两者互补关系，值得先啃透再动手。

2.1 用一张映射表把危害来源归位

标准表 1 给了一张“危害来源—危害事件原因—范围”的映射，这张表是整个流程的入口。我一般会把它改写成团队内部用的归类表，遇到一个危害事件先问“根因属于哪一栏”，再决定走哪条流程：

这张表的价值在于“分流”。一个感知误检导致的 AEB 误触发，根因是算法在特定光照下的性能局限，属于功能不足，走 SOTIF；如果是雷达供电模块虚焊导致输出漂移，那是故障，走功能安全。两者都要做，但分析方法和证据链完全不同。把分流做对，后面第 6 章的危害识别和第 7 章的触发条件分析才不会变成一锅粥。

2.2 因果模型决定了你的分析粒度

标准第 3 章给了 SOTIF 因果模型（图 2 到图 4），核心链条是：触发条件 → 功能不足 → 输出不足 → 危害行为 → 危害事件 → 伤害。这里有个容易被忽略的细节：功能不足分整车层面和要素层面。整车层面的功能不足被触发后直接产生危害行为；要素层面的功能不足被触发后先产生“输出不足”，再和其他要素的输出不足叠加，才促成整车层面的危害行为。

这个区分直接决定你的分析粒度。做要素级 FMEA 时你盯的是“这个摄像头在逆光下输出置信度掉到多少”，做整车级场景分析时你盯的是“逆光 + 前车白色 + 隧道出口”这个组合下整车会不会误判。标准注 4 举的 L2 高速公路辅助例子很典型：感知要素的功能不足被触发条件 1 触发产生危害行为，驾驶员监控摄像头的功能不足被触发条件 2 触发导致系统无法探测间接误用，两个功能不足叠加才构成完整伤害链。实际做分析时，我习惯先把因果链画成“触发条件—功能不足—输出不足—危害行为”四列，每一列单独填，填不出来的地方就是分析还没到位的地方。

2.3 接受准则是双层结构，别只做一层

标准 3.1 条把接受准则拆成两层：第一层判断某个车辆行为是否属于危害行为（危害行为接受准则），第二层判断一定里程或时间内残余风险是否处于合理水平（残余风险接受准则）。这个双层结构是很多团队漏掉的。只做第一层，你会得到一堆“这个行为有风险”的结论却无法回答“整体能不能放行”；只做第二层，你又说不清单个危害行为到底该不该拦。

落地做法是：第一层用物理参数卡，比如非预期横向加速度超过某个阈值、跟车距离低于某个值就判为危害行为；第二层用统计口径，比如每万公里危害行为事件数不超过某个量级。标准附录 E 给了风险接受准则示例，可以直接拿来改。注意标准注 3 提到指标值会随技术演变和交通环境变化而调整，所以这套准则要写成可维护的配置，别焊死在文档里。

3. 从规范定义到触发条件：把“没想到”变成可分析的条目

SOTIF 最反直觉的一点是：它要求你去分析“你没想到的东西”。标准第 5 章讲规范定义和设计，第 6 章讲危害识别和评估，第 7 章讲潜在功能不足和触发条件的识别与评估，这三章连起来才是完整的“找问题”流程。很多人卡在第 7 章，因为触发条件这东西不像故障模式那样有现成清单可查。

3.1 规范定义不足要写成可追溯的条目

标准 3.12 条对“规范定义不足”的定义是：可能不完整的规范定义，被触发条件触发后导致危害行为，或导致无法防止、探测及减轻合理可预见的间接误用。关键词是“可能不完整”。这意味着你不能等到发现 bug 才补，而是要在设计阶段主动列出“哪些地方我们其实没定义清楚”。

我一般会建一张规范定义检查表，按功能维度逐条过：

功能：高速公路辅助（L2） 检查项 是否明确 备注 ODD 边界（天气/道路类型/车速） 是 雨量阈值未量化 目标检测类别清单 否 未覆盖异形车辆 跟车距离策略（时距/最小距离） 是 低速段策略缺失 传感器失效降级策略 是 - 驾驶员监控告警升级时序 否 仅定义一级告警 人机交互模式提示 是 -

这张表里打“否”的条目，就是潜在的规范定义不足候选。标准注 3 特别提到，从规范定义、其他系统假设或系统性分析中衍生出的要求，也可以纳入“规范定义”范畴，所以这张表要包含衍生要求，不能只抄功能需求文档。填完之后每条“否”都要能对应到第 7 章的触发条件分析，形成闭环。

3.2 触发条件从场景因素里长出来

标准附录 B 给了推导 SOTIF 误用场景的方法和场景因素构建示例，B.3 还给了识别潜在触发条件和功能不足的安全分析示例。触发条件不是拍脑袋想的，而是从场景因素组合里推出来的。常见做法是把场景拆成道路、天气、交通参与者、自车状态、基础设施五类因素，每类列出可能影响感知或决策的具体取值，再做组合筛选。

举个具体例子：摄像头感知的触发条件可以从“光照”因素里推出逆光、隧道出入口明暗突变、夜间对向远光；从“目标特性”因素里推出白色车辆、异形货物、低对比度行人；从“天气”因素里推出大雨、浓雾、雪地反光。这些单独看都不致命，但“隧道出口 + 逆光 + 前方白色货车”组合起来就是典型的 SOTIF 危害场景。标准 B.4 还介绍了在 ADAS 和自动驾驶 SOTIF 研究中应用 STPA 方法，STPA 的好处是从控制结构出发找“不安全控制行为”，比纯场景枚举更容易覆盖到决策层的功能不足，团队里如果有系统安全背景的人，值得把这条方法用起来。

3.3 预估系统响应的可接受度

标准第 7 章有一节专门讲“预估系统对触发条件的响应的可接受度”。这一步是把触发条件和功能不足对上之后，判断系统当前响应是否可接受。做法上可以给每个“触发条件—功能不足”对打两个分：发生概率等级和后果严重度等级，再对照接受准则判断是“可接受”“需改进”还是“不可接受”。

这里有个血泪经验：不要用功能安全那套 S/E/C 参数直接套。SOTIF 的场景发生概率跟暴露率不是一回事，很多触发条件在正常路测里几乎采不到样本，比如特定角度的低太阳高度角加特定路面材质反光。这时候要么用仿真补样本，要么用专家判断加保守假设，并在文档里写清楚假设依据。标准第 10 章和第 11 章分别讲已知场景和未知场景的评估，本质上就是在回答“样本不够怎么办”——已知场景靠验证，未知场景靠确认策略和运行阶段监控兜底。

4. 验证与确认怎么排：已知场景、未知场景和残余风险三条线

标准第 9 到第 11 章是整份文件里最“工程”的部分：定义验证和确认策略、已知场景评估、未知场景评估。这三章解决的是“分析完了，怎么证明风险真的降下来了”。很多团队在这里翻车，不是因为方法不会，而是因为把三条线混着做，最后证据链对不上。

4.1 验证和确认策略要先定目标再选手段

标准第 9 章明确要求先定义集成和测试策略，再往下拆。附录 C 给了确认目标的导出方法和减少确认测试的考虑。我习惯按“目标—手段—证据”三层来排：

这张表的关键是最后一列的“证据”。标准反复强调工作成果（work product），每个阶段都有对应的输出物要求。实际做的时候，证据要能回溯到具体的触发条件和功能不足条目，否则审核时说不清覆盖了什么。附录 C.5 讲场景参数化和场景抽样指导，C.6 讲减少确认测试的考虑，这两节对测试资源紧张的团队很实用——不是所有组合都要实车跑，参数化之后用仿真做覆盖筛选，实车只跑高风险子集。

4.2 已知场景评估要分感知、规划、执行三层

标准第 10 章把已知场景评估拆成感知验证、规划算法验证、执行验证和系统集成验证。这个拆法有讲究：感知层看的是检测和分类在触发条件下的表现，规划层看的是决策在边界场景下是否合理，执行层看的是控制指令落地后的车辆行为，集成层看的是三层串起来会不会互相放大误差。

实操中我建议每层单独设通过判据，别用一个整车级指标糊过去。比如感知层用检测率、误检率、置信度分布；规划层用轨迹合理性、跟车时距偏差、换道决策时机；执行层用横向加速度跟踪误差、纵向减速度响应延迟。集成层再定义一个“危害行为发生率”作为总口径。这样某一层出问题时能快速定位，而不是整车测试跑完发现不对再回头一层层拆。标准 10.5 节讲已知危害场景导致的残余风险评估，这一步要把前面各层的通过情况和残余风险接受准则对上，形成“已知场景残余风险可接受”的结论。

4.3 未知场景靠确认策略和运行监控兜底

标准第 11 章讲未知场景评估，核心逻辑是：你不可能穷举所有场景，所以要用确认策略（validation）来建立“未知场景下残余风险可接受”的信心，再用第 13 章的运行阶段活动做持续监控。附录 C.3 讲预期功能安全适用系统的确认，C.4 讲感知系统的验证和确认，这两节是未知场景评估的主要参考。

这里有个容易走偏的地方：有人把“未知场景评估”理解成“多跑路测”。路测当然要跑，但标准要的是有策略的确认，不是里程堆砌。常见做法是先用仿真做大规模场景外推，找出高风险场景簇，再用实车在受控条件下复现验证，最后用运行阶段监控数据反哺。标准 11.3 节讲未知场景残余风险评估，评估结论要能回答“在现有确认证据下，未知场景导致的残余风险是否处于合理水平”。这个结论不是一次性的，第 13 章要求运行阶段持续观察和评估 SOTIF 问题，发现问题要走评估和解决流程，形成闭环。

5. 避坑清单：这五处我见过太多人栽进去

5.1 把 SOTIF 当成功能安全的附录

现象：团队把 SOTIF 分析塞进功能安全 HARA 的同一个工作表，用同一套 S/E/C 参数打分，最后 SOTIF 部分草草收尾。 原因：没理解两者是互补关系而非包含关系，标准引言和 A.2 明确说功能安全假定预期功能是安全的，SOTIF 处理的恰恰是“功能本身没问题但表现不足”的那部分。 解决：分开建表、分开定接受准则，只在整车危害事件层面做关联。表 1 的映射关系拿来当分流依据，别混着打分。

5.2 触发条件只列天气和道路，漏掉人和基础设施

现象：触发条件清单里全是雨雾雪、弯道坡道，分析做完发现覆盖不了实际路测中出现的误用问题。 原因：标准第 3 章明确把合理可预见的误用和基础设施信息纳入 SOTIF 范围，附录 D.4 还专门讲 V2X 功能的考虑，只盯自然环境因素会漏掉一大块。 解决：按道路、天气、交通参与者、自车状态、基础设施五类因素建清单，误用场景单独用附录 B.1 的方法推导，HMI 相关的模式混淆单独列。

5.3 接受准则只做一层就宣布放行

现象：所有危害行为都按物理阈值判了一遍，结论是“单个行为都可接受”，但整体放行时说不出残余风险到底多大。 原因：漏了标准 3.1 条的双层接受准则，第一层管行为、第二层管残余风险，两层都要有结论。 解决：第一层用物理参数卡危害行为，第二层用事件率或里程统计卡残余风险，两层结论分开写、分开评审。附录 E 的示例可以直接改。

5.4 验证确认只跑实车，仿真和场景抽样缺位

现象：确认阶段资源全压在实车路测上，跑了几十万公里还是说不清未知场景覆盖了多少。 原因：没按第 9 章先定策略再选手段，附录 C.5 的场景参数化和抽样指导没用起来。 解决：先做场景参数化和仿真覆盖筛选，实车只跑高风险子集和仿真无法覆盖的部分，证据链按“目标—手段—证据”三层对齐。

5.5 运行阶段监控缺失，问题闭环断在发布后

现象：SOTIF 活动做到确认发布就结束了，量产后的现场问题没有回流到 SOTIF 流程。 原因：忽略了第 13 章运行阶段的活动要求，SOTIF 问题评估和解决流程没建起来。 解决：把现场监控指标（危害行为事件、触发条件命中、误用告警）接入运行监控，发现问题走第 13 章的评估和解决流程，回流到第 5 到第 8 章的修改环节。附录 D.6 的 OTA 更新 SOTIF 考虑也要纳入变更管理。

6. 拿这份中文版当工作底稿：三个能立刻上手的用法

这份 GB/T 3267 征求意见稿最大的价值不是“读完”，而是“拆开用”。我拿到任何一份标准草案，第一件事不是从头读到尾，而是先定位它能嵌进现有流程的哪个环节。这份文件我一般拆成三块用。

第一块是术语和因果模型，直接抽出来做团队培训材料。第 3 章的术语定义比很多二手解读准确得多，尤其是“功能不足”“规范定义不足”“间接误用”这几个词，团队里理解不一致会导致分析结果对不上。因果模型那几张图可以重画成内部版，把自家系统的要素名填进去，比空对空讨论有效。

第二块是附录里的方法示例。附录 A.1 用 GSN 构建 SOTIF 论证的示例，适合拿来做安全案例的论证结构模板；附录 B.3 的安全分析示例和 B.4 的 STPA 应用，适合做触发条件识别的工作坊材料；附录 C.5 的场景参数化和抽样指导，适合直接改成测试团队的场景库规范。这些附录是资料性的，不强制，但恰恰是落地时最缺的“怎么干”的部分。

第三块是工作成果清单。标准每章末尾都有“工作成果”小节，把这些条目汇总成一张交付物检查表，按阶段挂到项目里程碑上，比临时想“这个阶段该交什么”靠谱得多。下面这张表是我按章节整理的简化版，实际用的时候按项目裁剪：

最后说一个验证方法上的技巧：拿到这份草案后，别急着全流程铺开，先挑一个已有功能做一次“迷你 SOTIF 走查”——选一个 L2 功能，按第 5 章列规范定义不足，按第 7 章推触发条件，按第 10 章排已知场景验证，走完一圈看哪个环节卡得最厉害，那个环节就是团队下一步要补的能力短板。我见过太多团队一上来就买工具、建大平台，结果流程没跑通，工具全成了摆设。从那以后我每次引入新标准都强制先做一次小范围走查，把卡点摸清楚再决定投入方向。希望这份拆解能帮你在 SOTIF 落地上少走几段弯路。

本文还有配套的精品资源，点击获取