汽车电子ISO 21448 SOTIF系列（第8期）：什么是“功能不足”？系统没坏但就是不行
原文链接：https://mp.weixin.qq.com/s/bjSq6JLlANud_UDrZJj4_A
🚗
一句话总结：本文深入拆解SOTIF最核心的概念——“功能不足”（Functional Insufficiency），讲清楚它为什么是SOTIF的“靶心”、规范不足和性能局限两种类型有什么区别、它们长什么样，以及一个系统的“菜”往往藏在设计文档的字缝里。
🤔 先回答一个“SOTIF的灵魂拷问”
上期我们认全了SOTIF的所有“黑话”——功能不足、触发条件、危害、四象限场景……
有读者问了一个特别“核心”的问题：
“SOTIF的核心是‘功能不足’——但功能不足到底长什么样？怎么判断一个系统‘行不行’？”
问到了SOTIF的本质！
打个比方：
一个学生考试考砸了，可能有两种原因：原因一：身体不舒服 🤒 ——“坏了”（硬件失效/软件bug），属于ISO 26262的范畴原因二：这题根本不会做 😰——“菜”（功能不足），属于SOTIF的范畴
功能不足，就是系统“本来就不会做”的那些事。
它不是“坏了”，是“设计的时候就没考虑到”或者“技术能力就到这了”。
💡 ISO 21448对功能不足的官方定义：“传感器、执行器和算法实现（包括神经网络和概率计算）中的不足之处。”
一个系统的“菜”，往往藏在设计文档的字缝里——不是在代码里，不是在芯片里，而是在“这个功能本来应该做什么”的定义里。
🎯 为什么功能不足是SOTIF的“靶心”？
还记得第3期我们说过的那句话吗？
ISO 26262的整个逻辑建立在“预期功能是安全的”这个假设之上。
但问题是——这个假设不一定成立。
如果一个功能的设计本身就有问题，那不管你怎么加固硬件、怎么写安全代码，它该出事还是会出事。
功能不足就是SOTIF要打的“靶子” 。SOTIF的整个流程——分析、设计、验证、确认——都是围绕着“找出功能不足、解决功能不足”展开的。
💡 一个惊人的数据：根据美国加州DMV发布的自动驾驶车辆脱离报告，69%的测试脱离是由于某种形式的功能不足导致的。失效事件的数量是系统故障事件的五倍。
也就是说，在自动驾驶测试中，因为“系统不行”导致的问题，比“系统坏了”多五倍。
这就是为什么SOTIF如此重要——功能安全解决的只是冰山一角，SOTIF要解决的是冰山在水下的那部分。
🧩 功能不足的“两大门派”：规范不足 vs 性能局限
ISO 21448将功能不足细分为两种类型：
| 类型 | 大白话 | 本质 |
|---|---|---|
| 📋 规范不足（Specification Insufficiency） | “没想到”——设计时就没考虑到这个场景 | 设计文档的“漏洞” |
| 📊 性能局限（Performance Limitation） | “做不到”——技术能力上限就在这了 | 物理/技术的“天花板” |
💡 简单记：规范不足 = “没考虑到”——是认知问题性能局限 = “做不到”——是能力问题
📋 门派一：规范不足——“没想到”
规范不足指的是系统设计规范本身就不完整——有些场景在设计时压根儿就没被考虑进去。
这不是“代码写错了”，是“需求文档里就没写”。
🔥 实战案例1：车道保持系统的“视野盲区”
假设你设计了一个车道保持系统，规范里写的是：“系统应使车辆保持在车道中央行驶。”
看起来没问题对吧？
但规范里没写的是：
“当车道线被积雪覆盖时，系统应该怎么办？”
摄像头正常工作、算法没有bug、执行器也没坏——但车道线被雪盖住了，系统“看不见”车道，不知道往哪走。
这就是规范不足——设计时就没考虑到“下雪天车道线被覆盖”这个场景。
🔥 实战案例2：ACC的“跟车距离漏洞”
一篇关于SOTIF的学术论文给出了一个更具体的例子：
某车型的E2LCACC（高速公路领航辅助系统）的规范中，没有完整定义跟车距离（headway distance）在不同车速下的具体值。
结果在高速行驶中，系统计算的跟车距离不足，导致与前车的安全裕度不够。
不是雷达测距不准（那是性能局限），是规范里根本就没规定“120km/h时应该保持多少米”。
🔥 实战案例3：高速公路匝道上的“陌生路牌”
同样的研究还给出了另一个例子：
系统规范中只包含了“标准高速公路路牌”的识别能力。但在某次实际行驶中，车辆遇到了一个不常见的高速公路匝道指示牌——这个路牌不在系统的规范里，系统“不认识”它。
结果：系统无法正确处理这个路牌的信息，做出了错误的导航决策。
规范不足的本质：系统的设计者没有预见到所有可能的场景。在复杂的真实世界中，“没想到”的事，永远比“想到”的事多。
📊 门派二：性能局限——“做不到”
性能局限指的是系统的技术能力本身就有上限——不是没考虑到，是“能力就到这了”。
这是物理规律、技术瓶颈、成本约束共同决定的“天花板”。
🔥 实战案例1：雷达的“物理盲区”
毫米波雷达有一个众所周知的物理局限——对非金属材料的反射信号极弱。
一个货车的货箱如果是非金属材质（比如玻璃钢、塑料），对雷达来说几乎是“透明”的。
不是雷达坏了——这是毫米波雷达的物理原理决定的。你换一万个雷达，结果都一样。
这就是性能局限——“做不到”。
🔥 实战案例2：摄像头的“天气限制”
摄像头在强逆光、雨雾、夜间等条件下的识别能力会显著下降。
某学术研究分析了雾天条件下视觉感知系统的SOTIF问题。研究发现，当能见度低于某个阈值时，视觉感知系统的目标检测准确率会急剧下降。
不是摄像头坏了——是光学传感器在恶劣天气下天生就“看不清”。
🔥 实战案例3：计算能力的“实时性瓶颈”
一个更隐蔽的性能局限是计算能力不足。
自动驾驶系统需要在毫秒级的时间内完成感知、决策、规划、控制的完整链条。如果某个环节的计算超时——哪怕只是晚了50ms——可能导致决策延迟。
不是算法写错了——是算力不够在限定时间内完成计算。
🔥 实战案例4：感知预测的“不确定性”
还有一个更“软”的性能局限——预测本身就不可能是100%准确的。
想象一个场景：一个行人站在路边，面前有一滩积水。感知系统“看到”了行人，但无法确定他会不会绕过积水过马路。
系统做出了一个预测——“行人会继续站在路边”。但这个预测可能是错的。
不是感知系统“看错了”，是它无法100%确定一个人类下一秒会做什么。这是任何预测系统都无法消除的“认知天花板”。
🔄 功能不足怎么被“激活”？触发条件的角色
功能不足本身不会造成事故。它需要被一个触发条件（Triggering Condition） 激活。
举个栗子🌰：
| 环节 | 内容 |
|---|---|
| 🧠 功能不足 | 雷达对非金属物体反射弱（性能局限） |
| 🌧️ 触发条件 | 前方是一辆非金属货箱的货车 + 夜间行驶 |
| 💥 危害 | 系统“看不见”货车，没有制动 |
| 😱 伤害 | 高速追尾 |
关键洞察：功能不足一直在那里，但只有在特定的触发条件下，它才会变成危险。
这就是为什么SOTIF要做“触发条件分析”——找出那些会让“功能不足”变成“危险行为”的具体场景。
📋 功能不足的类型对照表
| 类型 | 子类型 | 大白话 | 典型例子 |
|---|---|---|---|
| 📋 规范不足 | 整车级规范不足 | “整车功能定义就有问题” | ACC的跟车距离规范不完整 |
| 📋 规范不足 | E/E要素级规范不足 | “某个零件的需求没写全” | 系统不认识不常见的路牌 |
| 📊 性能局限 | 感知局限 | “传感器看不全/看不清” | 雷达对非金属不敏感、摄像头雨天看不清 |
| 📊 性能局限 | 算法局限 | “算不对/算不过来” | 行人轨迹预测错误、计算性能不足 |
| 📊 性能局限 | 执行局限 | “动作做不准” | 转向系统的执行能力有限 |
💡 GB/T 43267-2023（中国版SOTIF）的定义：功能不足包括“整车层面预期功能规范定义的不足”和“系统中电气/电子要素实现的规范定义不足或性能局限”。
🧠 本期重点回顾
| 核心要点 | 一句话总结 |
|---|---|
| 🎯 功能不足是SOTIF的“靶心” | SOTIF的整个流程就是“找出功能不足、解决功能不足” |
| 📋 规范不足 | “没想到”——设计时就没考虑到的场景 |
| 📊 性能局限 | “做不到”——技术能力的物理上限 |
| 🔄 触发条件激活功能不足 | 功能不足一直在那里，只有在特定场景下才会变成危险 |
| 📊 69%的脱离因功能不足 | 自动驾驶测试中，“不行”比“坏了”多五倍 |
📢 下期预告
【第9期】：什么是“触发条件”？什么情况下会“暴露”？
今天我们学会了“功能不足”——系统“本来就不会做”的那些事。
下期咱们聊聊触发条件（Triggering Condition） ——功能不足在什么具体情况下会被激活？触发条件和场景是什么关系？一个功能不足可能对应几十个触发条件，怎么找出它们？
敬请期待！
系列简介：《汽车电子ISO 21448 SOTIF深度解析》共计40期，系统讲解预期功能安全标准的完整知识体系。从概念到实践，从理论到落地，层层递进，帮你构建从入门到精通的SOTIF知识体系。本期为第8期。
💡 如果觉得有帮助，欢迎点赞、在看、转发三连！你的支持是我持续输出的最大动力～
💡 喜欢请持续关注 【AI超级个体实践】 ，更多硬核内容持续输出！