本文是「搞一下预期功能安全SOTIF」的第2篇。
第1篇我们介绍了SOTIF的基本概念和为什么需要它。本篇我们将深入ISO 21448标准内部，用一张V模型图带你看懂9大核心章节的完整流程体系。

---

前言：为什么要先建立全局视野？

在开始逐章啃标准之前，先建立一张完整的"地图"非常重要。ISO 21448不是零散条款的堆砌，而是一个从概念到运营、从分析到验证、从已知到未知的完整闭环体系。只有理解了各章节之间的逻辑关系，才能在实际项目中知道"先做什么、后做什么、谁和谁有关系"。

ISO 21448的主体内容是第5章到第13章，共9个核心章节，构成了一个经典的V字形开发模型。下面这张图是我根据标准内容整理的SOTIF全生命周期流程图：

图1：ISO 21448 SOTIF 开发V模型与全生命周期

---

一、V模型全景：左右对照，迭代闭环

SOTIF的V模型可以分为左侧（分析设计）、右侧（验证确认）、**顶部（策略层）和底部（运行层）**四个部分。

1.1 左侧：分析设计阶段（自上而下）

V模型的左侧是从宏观到微观的分解过程，回答"我们要做什么、风险在哪、怎么改"的问题：

章节	名称	核心任务	类比功能安全
第5章	功能与系统规范	定义预期功能是什么、在什么条件下运行（ODD）、系统架构如何	相关项定义（Part3）
第6章	危害识别与风险评估	识别系统可能的危害行为，评估风险等级，定义接受准则	HARA分析（Part3）
第7章	触发事件识别与评估	深挖根因：是什么功能不足、在什么触发条件下导致了危害行为	安全分析（FMEA/FTI）
第8章	功能改进与风险降低	设计改进措施，从系统、限制、移交、误用四个维度降低风险	安全概念/安全措施

1.2 右侧：验证确认阶段（自下而上）

V模型的右侧是从微观到宏观的集成验证过程，回答"改得对不对、够不够、能不能发布"的问题：

章节	名称	核心任务	类比功能安全
第10章	已知场景验证	针对已识别的场景，用仿真/台架/场地测试验证改进措施有效性	集成验证/系统测试
第11章	未知场景确认	通过路试、随机仿真等手段探索未知场景，评估残余风险	整车确认/安全验证
第12章	SOTIF发布评估	综合所有证据，判断SOTIF目标是否达成，做出发布决策	安全评估/发布认可

1.3 顶部与底部：贯穿全生命周期的活动

• 顶部（第9章）V&V策略定义：在验证活动开始之前，先明确验证目标、方法、覆盖度要求和接受准则。它就像一份"考试大纲"，指导第10章和第11章的具体执行。
• 底部（第13章）运行阶段活动：发布不是终点。车辆上路后，还要持续监控SOTIF事件、收集现场数据、通过OTA持续改进，形成迭代优化闭环。

---

二、九章速览：每一章到底在讲什么？

下面我们用最精炼的语言，把第5章到第13章的核心内容快速过一遍，让你对每一章的定位有个清晰的认知。

🔹 第5章：功能与系统规范 — SOTIF的基石

“你连功能是什么都说不清楚，还谈什么安全？”

第5章是一切SOTIF活动的起点。它要求你清晰地定义：

• 预期功能：这个功能到底要做什么？目标是什么？
• 设计运行范围（ODD）：功能在什么条件下可用？什么天气？什么道路？什么速度范围？
• 系统架构：功能由哪些要素组成？传感器、算法、执行器之间是什么关系？
• 人机交互（HMI）：系统如何跟驾驶员交互？提醒方式、接管逻辑是什么？

关键理解：第5章定义的不是"安全要求"，而是"功能本身的定义"。功能定义得越清晰，后续的危害分析和风险评估才越有的放矢。

🔹 第6章：危害识别与风险评估 — 找准靶心

“哪些危害行为是不可接受的？我们要对哪些问题负责？”

第6章的核心任务是从功能出发，识别出所有可能的危害行为，并评估其风险等级。

这里有两个关键概念：

• 危害行为（Hazardous Behavior）：系统的某种行为可能直接导致危险（比如AEB误刹、LCC突然偏离车道）
• 危害事件（Hazardous Event）：危害行为在特定场景下导致的实际伤害事件（比如AEB误刹导致后车追尾）

与功能安全（ISO 26262）不同，SOTIF的风险评估没有ASIL等级，而是采用两层接受准则：

1. 危害行为接受准则：评估严重度（S）和可控性（C）
2. 残余风险接受准则：对于不可接受的危害行为，定义残余风险要降到什么程度

🔹 第7章：触发事件识别与评估 — 深挖根因

“为什么会出现危害行为？背后的’凶手’是谁？”

如果说第6章是在看"危害行为造成了什么后果"，那么第7章就是在找"危害行为是怎么发生的"。

第7章要回答两个问题：

1. 潜在功能不足：系统本身有什么性能局限或规范缺陷？（比如摄像头在雨天识别率下降）
2. 触发条件：在什么具体场景下，这个功能不足会被"触发"为危害行为？（比如雨天+逆光+前车急停）

分析方向有两种：

• 正向推导：从已知的功能不足出发，推导可能触发的场景
• 反向追溯：从环境条件和误用场景出发，反推可能暴露的功能不足

🔹 第8章：功能改进与风险降低 — 对症下药

“找到了问题，怎么解决？”

第8章是"开药方"的章节。针对第7章识别出的功能不足和触发条件，通过四大类措施来降低风险：

措施类型	说明	举例
系统修改	改进系统本身的性能	升级传感器、优化算法、增加冗余
功能限制	在特定条件下限制功能的使用	弱光条件下降低LCC可用速度上限
权限移交	让驾驶员接管控制权	环境感知降级时HMI提醒驾驶员接管
误用预防	防止驾驶员的不合理使用	脱手检测+座椅震动提醒

关键理解：SOTIF的改进措施不是"加功能"，而是"控风险"。有时候主动限制功能（比如告诉用户"这个场景我不行"）比硬撑着做更安全。

🔹 第9章：V&V策略定义 — 制定考试大纲

“怎么证明你做的改进是有效的？用什么方法、测多少、达到什么标准才算过？”

第9章是承上启下的关键章节。在动手做验证之前，先把策略定清楚：

• 验证目标：要验证什么？（残余风险可接受？功能要求满足？ODD覆盖充分？）
• 验证方法：用什么手段？（SIL仿真？HIL台架？封闭场地？公共道路？）
• 覆盖度要求：怎么证明测够了？（场景覆盖率？参数组合覆盖率？里程数？）
• 接受准则：达到什么指标算通过？

🔹 第10章：已知场景验证 — 闭卷考试

“针对我们已经知道的风险场景，改进措施真的起作用了吗？”

第10章聚焦已知场景的验证。这些场景是从第5-7章的分析中推导出来的，我们"知道它们存在、知道它们可能有风险"。

验证手段通常包括：

• SIL（软件在环）仿真：快速、低成本、可遍历大量参数组合
• HIL（硬件在环）台架：接近真实硬件，验证实时性和接口
• 封闭场地测试：最接近实车，但成本高、场景有限

核心指标：场景覆盖度、测试用例通过率、功能性能指标

🔹 第11章：未知场景确认 — 开卷考试

“我们不知道的那些场景呢？万一遇到’黑天鹅’怎么办？”

第11章是SOTIF最有挑战性的章节——如何评估我们不知道的风险？

未知场景的确认方法：

• 长距离实车路试：在公共道路上跑百万公里，用真实世界"碰"场景
• 随机仿真与探索性测试：用算法自动生成海量场景，探索系统边界
• 对抗性测试：故意构造Corner Case，测试系统极限
• 众包数据采集：从大量用户车辆收集真实场景数据

最终目标是证明残余风险（未知不安全场景）足够低，通常用统计论证方法（比如"事故率低于人类驾驶员平均水平"）。

🔹 第12章：SOTIF发布评估 — 交卷打分

“所有证据都齐了，到底能不能发布？”

第12章是"终审环节"。综合前面所有章节的产出，评估SOTIF目标是否达成：

• 流程完整性：该做的活动都做了吗？
• 证据充分性：验证数据够不够？覆盖度够不够？
• 风险可接受性：残余风险在可接受范围内吗？

发布结论通常有三种：

• ✅ 接受：SOTIF目标达成，可以发布
• ⚠️ 有条件接受：基本达成，附带一些条件或后续行动
• ❌ 拒绝：证据不足或风险过高，需要继续改进

🔹 第13章：运行阶段活动 — 终身质保

“车卖出去就完事了？SOTIF才刚刚开始。”

第13章把SOTIF从开发阶段延伸到了车辆的整个生命周期：

• 现场监控：部署数据记录系统（如DSSAD），实时记录车辆运行状态
• 事件响应：建立SOTIF事件上报、分析、响应流程
• 持续改进：根据现场数据发现新的风险场景，通过OTA等方式更新
• 风险再评估：定期或在重大更新后重新评估SOTIF状态

这一章体现了SOTIF的迭代闭环思想——安全不是一次性的认证，而是一个持续优化的过程。

---

三、四象限模型：SOTIF的核心思想

理解了9章内容之后，我们再用一个经典的四象限场景模型来提炼SOTIF的核心思想：

图2：SOTIF四象限场景模型

所有车辆运行场景可以按照**“已知/未知"和"安全/不安全”**两个维度分成四类：

象限	场景类型	特点	SOTIF处理方式
↖️左上	已知安全	已识别、确认无风险	安全区，目标是持续扩大
↙️左下	已知不安全	已识别、有风险	Ch8改进措施 → Ch10验证消除
↗️右上	未知安全	未识别、实际安全	不构成风险，验证过程中逐步转化
↘️右下	未知不安全	未识别、有风险	核心攻坚目标，Ch11探索发现

SOTIF的终极目标可以用一句话概括：

把已知不安全的变安全，把未知不安全的变已知，让残余风险趋近于零。

这也解释了为什么SOTIF是一个无限趋近的过程——你永远无法证明"没有未知不安全场景"，只能通过不断的测试、运行、反馈，让残余风险低到可以接受的程度。

---

四、SOTIF与功能安全：章节映射关系

很多读者会问：SOTIF和ISO 26262（功能安全）是什么关系？它们的流程可以对应起来吗？

答案是：两者高度互补，流程结构相似，但关注点完全不同。

SOTIF（ISO 21448）	功能安全（ISO 26262）	关注点差异
Ch5 功能与系统规范	Part3 相关项定义	SOTIF更强调ODD和性能边界
Ch6 危害识别与评估	Part3 HARA分析	SOTIF无ASIL，不考虑暴露概率E
Ch7 触发事件与功能不足	Part4 安全分析（FMEA/FTI）	SOTIF分析的是"功能不足"而非"失效"
Ch8 功能改进措施	Part4/5 安全概念/技术安全概念	SOTIF措施更偏向功能和性能层面
Ch9-11 V&V策略与执行	Part6/8 集成验证/安全确认	SOTIF更强调场景覆盖和未知探索
Ch12 发布评估	Part2/8 安全评估/认可	评估框架类似，证据不同
Ch13 运行阶段监控	Part8 生产/运行	SOTIF更强调数据收集和功能迭代

一句话总结：功能安全关注的是"系统失效了怎么办"，SOTIF关注的是"系统没失效但功能不够好怎么办"。两者共同构成了智能驾驶的安全双保险。

---

五、小结

本篇我们用一张V模型图和一张四象限图，把ISO 21448的9大核心章节串了起来。

1. V模型结构：左侧分析设计（Ch5-8）→ 右侧验证确认（Ch10-12）→ 顶部策略（Ch9）→ 底部运行（Ch13）
2. 四象限思想：已知安全/已知不安全/未知安全/未知不安全，SOTIF就是不断缩小不安全区域的过程
3. 与功能安全的关系：流程相似、互补但不重叠，分别解决"失效"和"功能不足"两类问题

---