一、功能安全概述：什么是功能安全？为什么ADAS需要功能安全？功能安全与预期功能安全的区别

大家好，我是老张，在ADAS系统这行摸爬滚打了十几年。今天咱们开始聊功能安全，这是整个ADAS开发的基石。说实话，我刚入行那会儿，功能安全还没现在这么受重视，大家更关注“功能能不能跑起来”。直到有一次，我在一个AEB项目中遇到了误触发问题——嗯，那场景我现在还记得，测试车在空旷路段突然急刹，后车差点追尾。从那以后，我彻底明白了：功能安全不是锦上添花，是保命用的。

1.1 什么是功能安全？

功能安全，说白了就是：当系统出故障时，它不能伤人。

你想想看，一个ADAS系统，比如自适应巡航，如果雷达突然失效了，车应该怎么办？是继续加速？还是突然刹车？还是慢慢减速靠边？功能安全要回答的就是这类问题。

国际标准ISO 26262给的定义是：不存在由电子电气系统故障行为导致的不可接受风险。这里的关键词是“故障行为”——系统本身可能坏了，但它的“坏法”不能导致危险。

我个人习惯把功能安全比作“汽车的保险丝”。保险丝本身不产生价值，但没了它，整个电路都可能烧掉。功能安全也是这样——它不增加功能，但保证功能出问题时不出人命。

1.2 为什么ADAS需要功能安全？

这个问题其实很直接：ADAS系统直接控制车辆，而车辆是能杀人的机器。

我举个例子你就明白了。一个普通的娱乐系统，屏幕死机了，最多是导航看不了，司机骂两句。但ADAS系统呢？如果自动紧急制动（AEB）在关键时刻没反应，或者错误地触发——后果可能是追尾、撞人，甚至车毁人亡。

具体来说，ADAS需要功能安全的原因有三点：

1. 系统复杂度高：现在的ADAS系统，传感器、控制器、执行器加起来可能有几十个ECU。任何一个环节出问题，都可能引发连锁反应。我在项目中见过一个案例：摄像头因为散热不良导致图像延迟，结果车道保持系统误判，车直接往护栏上偏——还好测试员及时接管了。
2. 人机交互风险：ADAS不是完全自动驾驶，它需要人机共驾。如果系统突然退出，或者给出错误提示，驾驶员可能来不及反应。说白了，功能安全要保证“系统失效时，人还能兜得住”。
3. 法规强制要求：现在全球主要市场都要求ADAS系统通过功能安全认证。比如欧盟的GSR法规、中国的C-NCAP，都把功能安全作为准入门槛。你不做，车就卖不出去。

1.3 功能安全与预期功能安全的区别

这个问题很多人搞混，包括一些老工程师。我简单给你捋一捋。

功能安全（Functional Safety），对应ISO 26262，关注的是系统本身的故障。比如传感器坏了、软件跑飞了、线束断了——这些都是“系统内部错误”。

预期功能安全（Safety of the Intended Functionality, SOTIF），对应ISO 21448，关注的是系统在正常工作时，因为设计不足或场景局限导致的危险。比如：

• 传感器在强光下识别不准（不是坏了，是能力不够）
• 算法在罕见场景下决策错误（不是bug，是没考虑到）
• 系统在雨雪天气性能下降（不是故障，是物理限制）

你看，区别很明显：

维度	功能安全（ISO 26262）	预期功能安全（ISO 21448）
关注点	系统故障（硬件/软件失效）	功能局限（设计/场景不足）
典型问题	传感器坏了、芯片死机	强光下看不清、罕见场景误判
应对方法	冗余、诊断、故障响应	场景分析、性能边界测试、功能改进
标准	ISO 26262	ISO 21448

我打个比方你就懂了：

• 功能安全：就像你开车时刹车油管漏了（系统坏了），你得有备用刹车或者报警。
• 预期功能安全：就像你开车时遇到大雾，刹车距离变长了（系统没坏，但能力不够），你得知道这个局限，提前减速。

两者不是替代关系，是互补关系。一个完整的ADAS系统，两者都得做。我参与的一个L2+项目，前期只做了功能安全，结果路试时发现好几个场景下系统表现不稳定——后来补了SOTIF分析，才把问题都堵上。

知识体系总览

下面这张图，是我自己总结的本章知识结构。你可以把它当作一个“地图”，后面几章我们会逐一展开。

嗯，这张图把本章的核心逻辑串起来了。左边是功能安全，右边是预期功能安全，底部是两者的关系。你记住一句话就行：功能安全防“坏”，预期功能安全防“笨”。

---

好了，第一章就聊到这儿。内容不多，但都是基础中的基础。后面我们会深入ASIL等级、安全分析、SOTIF场景分析这些硬核内容。有什么问题，欢迎随时交流。