1. 课程导论：什么是功能安全（FuSa）与预期功能安全（SOTIF）？为什么需要协同设计？
大家好，欢迎来到这门课。我是你们的老朋友，一个在汽车电子领域摸爬滚打了十几年的工程师。今天咱们聊聊两个“安全”——功能安全和预期功能安全。说实话，我刚入行那会儿，这两个概念还没分得这么清楚。现在不一样了，它们是智能驾驶时代的“双保险”。
1.1 功能安全（FuSa）到底是什么？
功能安全，说白了就是“系统出故障了，也不能伤人”。
举个例子：你开车时，刹车踏板踩下去，但刹车没反应——这叫系统故障。功能安全要做的，就是确保这种故障发生时，系统能进入安全状态，比如自动紧急制动介入，或者至少给驾驶员一个明确的警告。
我习惯用一句话概括：功能安全处理的是“系统本身失效”带来的风险。它关注的是硬件随机失效、软件系统性失效这些“内部问题”。
核心标准：ISO 26262
这是功能安全的“圣经”。它定义了从ASIL A到ASIL D四个安全等级。ASIL D要求最高，比如转向、制动系统。我参与过一个ASIL D的项目，那真是“如履薄冰”，每个电阻、每行代码都要反复论证。
1.2 预期功能安全（SOTIF）又是什么？
预期功能安全，英文叫SOTIF（Safety Of The Intended Functionality）。这名字有点绕，但意思很直白：系统本身没坏，但它的“正常行为”可能带来危险。
你想想看，一个自适应巡航系统，传感器没坏，算法也没崩溃。但遇到大雨天，雷达被干扰，误以为前方有障碍物，突然急刹车——这就是SOTIF要解决的问题。系统功能是“正常”的，但场景超出了它的“预期能力”。
我在项目中遇到过类似情况：一辆测试车在隧道出口，阳光直射摄像头，导致车道保持系统短暂失效。硬件没坏，软件没崩，但就是“看不清”。这就是典型的SOTIF问题。
核心标准：ISO 21448
这个标准专门处理“功能不足”和“触发条件”带来的风险。它不关心芯片会不会坏，而是关心“这个功能在哪些场景下会表现不佳”。
1.3 两者的核心区别
很多新手容易搞混。我画个简单的对比表，你一看就明白：
| 维度 | 功能安全（FuSa） | 预期功能安全（SOTIF） |
|---|---|---|
| 关注点 | 系统故障（硬件坏、软件bug） | 功能不足（感知、决策、执行局限） |
| 典型场景 | 刹车踏板断裂、ECU死机 | 暴雨中摄像头看不清、鬼探头 |
| 标准 | ISO 26262 | ISO 21448 |
| 分析方法 | FMEA、FTA、FMEDA | STPA、HARA（场景驱动） |
| 安全状态 | 降级、关断、冗余切换 | 功能限制、驾驶员接管请求 |
嗯，这里要注意：功能安全是“已知的未知”——我们知道硬件可能坏，所以提前设计冗余。而预期功能安全是“未知的未知”——我们不知道系统会在哪个奇葩场景下“犯傻”。
1.4 为什么需要协同设计？
你可能会问：这两个东西分开做不行吗？
我告诉你，不行。原因有三：
- 风险会“串门”：一个SOTIF问题，可能被功能安全机制误判为故障。比如传感器被遮挡，功能安全以为是硬件失效，直接关停系统——这反而制造了新的危险。
- 成本翻倍：分开做，意味着两套分析、两套测试、两套文档。我见过一个项目，FuSa团队和SOTIF团队各干各的，最后发现安全目标互相矛盾，返工了三个月。
- 系统复杂度爆炸：现在的智能驾驶系统，感知、决策、执行环环相扣。一个“正常”的决策，可能因为感知的“功能不足”而变成危险行为。不协同设计，你根本理不清因果关系。
我的建议：从系统架构层面，就把FuSa和SOTIF的“安全目标”统一管理。比如，定义一个“安全状态”时，既要考虑硬件故障后的降级，也要考虑功能受限时的驾驶员接管。这两者应该是一个硬币的两面。
1.5 两者的联系：一张图看懂
为了让你更直观地理解，我画了一张框架图。它展示了功能安全与预期功能安全在系统开发中的位置和关系：
从这张图你可以看到：系统层是基础，功能安全和预期功能安全是两条并行的分析路径，但它们最终要在“协同设计层”汇合。我曾经在一个项目中，把FuSa的FMEA和SOTIF的STPA放在同一个工作坊里做，结果发现很多危害是“双重身份”——既是硬件故障，也是功能不足。协同设计，就是要把这些“双重身份”的风险一次性搞定。
1.6 避坑指南
我曾经踩过的坑：
- 别把SOTIF当成FuSa的“附属品”：有些团队觉得“先做完FuSa，再顺便搞搞SOTIF”。结果SOTIF分析发现的问题，FuSa的安全机制根本覆盖不了，只能推倒重来。
- 别忽视“正常功能”的风险：我见过一个团队，花了大半年做FuSa，把硬件冗余做得滴水不漏。结果上路测试，系统在雨夜把路边的水坑识别成障碍物，一脚急刹——后车追尾了。这就是典型的“功能正常但场景不对”。
- 文档要统一：FuSa和SOTIF的文档格式、术语、编号体系最好一致。否则后期审核时，你会被“这个危害在FuSa里叫H1，在SOTIF里叫H2”这种问题折磨疯。
1.7 小结
好了，这一章我们聊了：
- 功能安全处理“系统坏了怎么办”
- 预期功能安全处理“系统没坏但犯傻了怎么办”
- 两者必须协同设计，因为风险会交叉、成本会叠加、系统会变复杂
记住一句话：功能安全是“底线”，预期功能安全是“上限”。底线保命，上限保体验。两者缺一不可。
下一章，我们会深入聊聊功能安全的核心方法论——HARA（危害分析与风险评估）。到时候我会分享一个我亲手做过的案例，保证让你印象深刻。