简介：面向智能网联汽车功能安全从业者、系统与软件工程师及高校相关专业学习者，这份资料提供预期功能安全（SOTIF）领域两份核心标准的中文文本，即国际标准 ISO 21448 与国家标准 GB/T 3267，用于解决自动驾驶与辅助驾驶系统在无故障情形下因性能局限、感知偏差和算法约束而产生风险的评估与缓解问题。压缩包共 1 个 PDF 文件，约 40.15MB，内容为 GB/T 标准征求意见稿，涵盖规范定义与设计、危害识别与评估、潜在功能不足及触发条件分析、修改功能以解决 SOTIF 风险、验证与确认策略等章节，并附术语定义、工作成果要求与组织管理流程，可帮助读者系统梳理 SOTIF 全生命周期活动框架，对照条款开展风险分析与设计改进。目前已有 747 人学习下载，适合需要深入理解标准条文、搭建合规流程或开展培训参考的读者使用。
1. 预期功能安全到底在防什么：一个“没坏却出事”的困惑
想象一下这样的场景：一辆车在高速上开启了辅助驾驶，传感器没坏、芯片没烧、代码也没报错，可它就是没认出前方横在路中间的一辆侧翻货车，直直撞了上去。事后检查，所有零件都“合格”，所有模块都“正常”，那问题出在哪？这正是预期功能安全（Safety of the Intended Functionality，简称 SOTIF）要回答的问题。它关注的不是“东西坏了”，而是“东西没坏，但它的本事不够、或者被用错了地方”。换句话说，传统安全问的是“会不会突然失灵”，SOTIF 问的是“在它正常工作的前提下，有没有可能因为看得不够清、想得不够全、或者人用得不对而出事”。搞懂这个概念，你才能明白为什么一辆“没有故障”的智能车，依然需要一套专门的安全标准来兜底，也才能看懂 ISO 21448 和 GB/T 43267 这类文件到底在管什么。
2. 为什么“没坏”也需要一套安全标准：功能安全的盲区
2.1 功能安全管的是“故障”，管不了“能力不足”
要理解 SOTIF 为什么存在，得先看它的邻居——功能安全。功能安全的标准（对应 GB/T 34590 系列）盯的是电气/电子系统的故障：传感器短路了、芯片死机了、线束断了，这些都属于“异常表现”。它的逻辑是：只要我把故障率压到足够低，系统就是安全的。但智能驾驶系统有个特点，它的很多风险根本不来自故障。摄像头没坏，可逆光下就是看不清；雷达没坏，可大雨天回波就是一团糟；算法没崩，可它训练时就没见过“路上躺着一块床垫”这种场景。这些情况里，系统一切“正常”，但输出结果就是错的。功能安全对此无能为力，因为它假定“预期功能本身是安全的”，只负责防故障导致的偏离。SOTIF 补的正是这块空白：它假定没有故障，专门研究功能不足——也就是规范定义没写全、或者性能本身有局限——在特定条件下如何演变成危害。
打个比方，功能安全像是检查一辆车的刹车片有没有磨损、油管有没有漏油；而 SOTIF 关心的是，就算刹车片完好、油管通畅，这辆车的刹车距离在湿滑路面上是不是够用、驾驶员是不是误以为它能一脚刹停。前者防“坏”，后者防“不够”和“误用”。
2.2 智能驾驶把“能力边界”问题放大了
为什么这套标准近几年才被重视？因为驾驶自动化等级越高，系统承担的动态驾驶任务越多，人对环境的监控就越少，系统“能力不足”的后果就越严重。一辆 L2 级辅助驾驶车，如果摄像头在强光下漏检，理论上驾驶员还该盯着路面；但到了 L3 甚至 L4，系统自己负责感知和决策，一旦它的感知在某个边缘场景下失效，就没有人及时兜底。SOTIF 标准明确把适用范围锁定在“依靠复杂传感器和处理算法进行态势感知、且感知正确性对安全有重要影响”的功能上，尤其是紧急干预系统和 L1 到 L5 的驾驶自动化功能。它要做的，是在设计阶段就把“系统可能在哪些场景下看走眼、想岔了”提前挖出来，而不是等路上出了事再回头查。
2.3 它和功能安全是互补，不是替代
很多人第一次接触 SOTIF 会问：有了功能安全，为什么还要再来一套？答案在标准原文里写得很清楚：两者在安全方面是互补的。功能安全处理的是“因故障导致的危害”，SOTIF 处理的是“因功能不足导致的危害”。一个典型的智能驾驶危害事件，往往两者都有份：比如感知模块因为某个元件随机失效而输出错误（功能安全管），同时感知算法本身对某种天气条件就缺乏鲁棒性（SOTIF 管）。所以完整的做法是两条线并行，各自识别自己范围内的风险，再在整车层面汇合。标准附录里专门有一节讲这两套标准如何相互作用，就是为了防止团队把它们当成二选一的选择题。
3. SOTIF 的核心逻辑：从“功能不足”到“危害”的因果链
3.1 功能不足：规范没写全，或者本事就到这
SOTIF 整个体系围绕一个核心概念展开：功能不足。标准把它拆成两种。第一种叫规范定义不足，意思是功能规范本身就没考虑周全。比如自适应巡航的跟车距离规范写得太粗，导致某些车速下跟得太近；或者系统对“不常见的道路标识”压根没在规范里定义处理方式，遇到就懵。第二种叫性能局限，指的是所用组件和技术的固有天花板。摄像头在夜间低照度下的分辨率就是有限，毫米波雷达对静止物体的区分能力就是有边界，这些不是写错了规范，而是物理和算法层面的客观限制。功能不足可以是整车层面的，也可以是某个电子电气要素层面的。标准特别强调，在还没确认某个不足是否真的会导致危害之前，可以叫它“潜在功能不足”——这个措辞很务实，因为很多问题是在分析过程中才逐步坐实的。
3.2 触发条件：压垮骆驼的那根特定稻草
光有功能不足还不一定出事，得有一个触发条件把它引爆。触发条件可以是场景里的特定条件，比如强烈的逆光、隧道出口的明暗突变、路面上的积水反光、前方车辆装载了形状奇怪的货物。也可以是合理可预见的误用，比如驾驶员在系统设计运行范围之外强行激活功能，或者开着 L2 辅助驾驶却双手离开方向盘、注意力涣散。标准把误用分成直接误用和间接误用：直接误用本身可能直接诱发系统的危害行为，比如在市区道路激活了只适用于高速的功能；间接误用则是降低了人对危害行为的可控性，比如驾驶员睡着导致没能及时接管。这里有个关键边界：SOTIF 管的误用是“合理可预见”的，不包括故意更改系统、明显违反预期用途的乱来。也就是说，它防的是人之常情下的用错，不是防恶意破坏。
3.3 因果模型：不足被触发，输出就偏了
把上面两个概念串起来，就得到 SOTIF 的因果链：某个功能不足被某个触发条件激活，导致系统输出不足，进而产生整车层面的危害行为，如果此时人也没能防住、探测到或减轻这个行为，就可能演变成危害事件，最终造成伤害。标准用几张图把这个关系画得很细，还区分了要素层面和整车层面：要素层面的功能不足被触发后先产生输出不足，输出不足单独或和其他要素的输出不足叠加，才促成整车层面的危害行为。这个区分很重要，因为它决定了你在哪个层级做分析和改进。举个标准里的例子：一辆 L2 高速辅助驾驶车，感知要素存在功能不足，被触发条件一激发就会走错轨迹；同时驾驶员监控摄像头也有功能不足，被触发条件二激发就探测不到驾驶员走神。要真出伤害，得两个触发条件同时凑齐——驾驶员走神没接管，系统又正好走偏。这种多因素叠加的视角，是 SOTIF 分析区别于传统单点故障分析的地方。
4. 常见误区：SOTIF 容易和谁搞混
4.1 误区一：SOTIF 就是功能安全的升级版
易混点：名字里都带“安全”，又都针对道路车辆电子系统，很容易以为 SOTIF 是功能安全的新版本或加强版。为什么混：两者确实共享很多术语和整车层面的危害分析思路，标准里也反复对照着讲。怎么区分：看危害来源。功能安全的标准明确针对电气/电子系统的故障——随机硬件失效和系统性失效；SOTIF 明确排除故障，专攻“没有故障但功能不足”。标准原文有一张表把危害来源和对应标准做了映射：电气/电子系统故障归功能安全，功能不足、合理可预见的误用、基于人工智能算法的不足归 SOTIF。所以它们是两条并行线，不是版本迭代关系。
4.2 误区二：只要系统没报故障码，就没有 SOTIF 风险
易混点：日常开发里，故障码和诊断覆盖率是安全工作的显性指标，容易让人觉得“诊断全绿就等于安全”。为什么混：功能安全的很多工作确实围绕故障检测和响应展开，这套思维惯性会带过来。怎么区分：SOTIF 的风险恰恰藏在“一切正常”里。摄像头没坏、算法没崩，但它对某种场景就是处理不好，这种不足不会触发任何故障码。标准里讲的性能局限和规范定义不足，都是诊断系统看不见的。所以 SOTIF 要靠场景分析、危害识别、验证确认去挖，而不是靠读故障码。
4.3 误区三：误用都是用户的问题，不该算系统责任
易混点：一听到“误用”，第一反应是“那是用户乱来，跟设计有什么关系”。为什么混：日常语境里“误用”常带贬义，好像全是使用者的错。怎么区分：SOTIF 里的误用限定为“合理可预见”，标准明确把它纳入范围，并且要求系统具备防止、探测及减轻这类误用的能力。也就是说，如果一种误用是人之常情、可以预见的，设计方就有责任通过人机交互设计、驾驶员监控、功能限制等手段去降低风险。标准甚至把“无法防止、探测及减轻合理可预见的误用”本身也视为一种功能不足。所以它不是甩锅给用户，而是要求系统把人的不完美也考虑进去。
4.4 误区四：SOTIF 只适用于 L3 以上的自动驾驶
易混点：觉得只有高度自动驾驶才谈得上“预期功能”，低等级辅助驾驶没什么可分析的。为什么混：SOTIF 的讨论常和高阶自动驾驶一起出现，容易造成绑定印象。怎么区分：标准适用范围写的是 L1 到 L5 的驾驶自动化功能，以及紧急干预系统。L2 级辅助驾驶同样有感知局限和误用问题，比如驾驶员过度信任系统导致脱手脱眼，这正是 SOTIF 要管的典型场景。等级低不代表风险低，只代表人还在一部分环节里兜底，但兜底能力本身也可能被间接误用削弱。
5. 什么时候用、什么时候别用：一份边界判断
5.1 该用 SOTIF 的场景：感知决策类功能是主战场
判断一个功能要不要走 SOTIF 流程，核心看它是否“依靠复杂传感器和处理算法进行态势感知，且感知正确性对安全有重要影响”。典型的包括：各类驾驶自动化功能里的环境感知、目标识别、路径规划；自动紧急制动这类紧急干预系统；以及依赖地图、V2X 等外部信息辅助决策的功能。标准附录里还专门讨论了感知系统性能目标量化、机器学习应用、地图和 V2X 的 SOTIF 考虑，说明这些新技术形态都在射程内。反过来，如果某个功能已经有成熟可靠的设计和验证确认措施，比如动态稳定性控制、安全气囊这类传统系统，标准明确说不在预期使用范围内。这不是说它们不重要，而是它们的风险模式已经被既有方法覆盖得比较充分，不需要再套一层 SOTIF 分析。
5.2 不该硬套 SOTIF 的场景：故障、信息安全、故意滥用
有几类问题容易被误装进 SOTIF 的筐里，需要拎清楚。第一类是纯粹的电气/电子故障，那是功能安全的地盘，SOTIF 标准开篇就说不适用于功能安全涵盖的故障。第二类是信息安全威胁，比如利用车辆漏洞进行攻击，这归信息安全标准管，标准表格里也做了映射。第三类是系统技术直接导致的危害，比如激光雷达光束对眼睛的伤害，这属于特定产品安全标准的范畴。第四类是明显违反预期用途的故意行为，标准把它定义为功能滥用，排除在合理可预见的误用之外。把这些边界划清，不是为了推卸，而是为了让每类风险落到最合适的分析方法上，避免用错工具导致该挖的没挖到、不该花的力气花了一堆。
5.3 一个具体判断例子：车道保持辅助该不该做 SOTIF
拿一个常见的 L2 级车道保持辅助功能来走一遍判断。它依赖摄像头感知车道线，感知正确性直接影响车辆是否跑偏，显然属于“感知对安全重要”的功能，该做 SOTIF。分析时先找功能不足：摄像头在车道线磨损严重、雨夜反光、强光直射时可能识别不稳，这是性能局限；规范里对“车道线短暂消失后如何保持”如果定义不清，这是规范定义不足。再找触发条件：施工路段临时改道、旧标线和新标线重叠、路面有大量阴影。然后看误用：驾驶员因为系统表现稳定而双手离开方向盘，属于合理可预见的间接误用，系统若有驾驶员监控就该能探测并提醒。对应的改进可能包括：优化感知算法对低对比度车道线的鲁棒性、在规范里补上车道线丢失时的降级策略、通过人机交互明确提示功能边界。这一圈走下来，你会发现 SOTIF 不是一张要填的表，而是一种把“系统会在哪儿不够用、人会在哪儿用错”提前想一遍的习惯。
我自己的教训是，早些年看这类标准总想找一张“检查清单”照着打勾，结果漏掉了因果链里最关键的“触发条件”那一环——功能不足列了一堆，却没想清楚它们在什么场景下才会被引爆，分析就流于形式。从那以后我每次碰感知相关功能，都强制先把“不足、触发条件、危害行为”这条链子完整走一遍再往下写。希望这个思路帮到你。这份资料把标准正文连同多个资料性附录一起收进来，从危害识别评估到验证确认策略、从场景分析到机器学习建议都有展开，适合放在手边随时对照着捋因果链。
本文还有配套的精品资源，点击获取
