1. 功能安全概述：什么是功能安全？为什么AD系统需要功能安全？功能安全的历史与发展
1.1 什么是功能安全？
功能安全，说白了就是「系统出故障时，也不能伤到人」。
我经常跟刚入行的同事讲：功能安全不是让系统永远不出错——那是不可能的。而是当系统出错时，它还能安全地停下来，或者进入一个不会造成伤害的状态。
举个例子。你开车时，ACC（自适应巡航）突然失效了。如果系统只是「啪」一下断开，车瞬间失去动力，那后果不堪设想。但功能安全要求的是：ACC失效时，系统要平滑退出，同时提醒驾驶员接管。这就是功能安全在干活。
核心定义：功能安全是「不存在由系统功能异常导致的不可接受风险」。它关注的是系统在发生故障时的行为，而不是系统本身的功能性能。
这里有个关键点——功能安全不等于「质量好」。质量好是说系统不容易坏，功能安全是说「坏了也能兜住」。我在项目里见过不少团队把这两件事混在一起，结果安全机制没做透，质量测试倒是堆了一堆。嗯，方向偏了。
1.2 为什么AD系统需要功能安全？
这个问题其实很简单：因为AD系统会直接控制车辆的运动。一旦出问题，后果可能是人命。
你想想看，传统汽车里，刹车踏板踩下去，是机械连杆直接推动制动主缸。就算电子系统全挂了，你使劲踩还能刹住。但AD系统不一样——它通过线控、传感器、算法来决定「要不要刹车」。如果软件跑飞了，或者传感器被遮挡了，系统可能根本不知道前面有障碍物。
我参与过一个L2+的项目，测试时发现一个场景：摄像头被强光直射后，目标检测短暂丢失。如果这时候前方有静止车辆，系统会误以为车道是空的，直接加速。这就是典型的「功能不安全」——系统没坏，但行为是危险的。
所以，AD系统需要功能安全，原因有三：
- 危害严重性高：AD系统失效可能导致碰撞、伤亡，这是不可接受的。
- 系统复杂度高：软件、硬件、传感器、执行器交织在一起，故障模式多到数不清。
- 法规强制要求：ISO 26262、ISO 21448等标准已经明确要求AD系统必须满足功能安全。
我的经验：很多团队在项目初期觉得「功能安全是合规部门的事」，等到系统集成测试时才发现安全机制没设计好，改起来成本极高。我建议在系统架构阶段就把功能安全放进去，而不是最后补。
1.3 功能安全的历史与发展
功能安全不是新鲜事。它的发展，其实是一部「血的教训史」。
1.3.1 早期：从工业控制开始
上世纪70年代，化工、核电等行业开始关注安全系统。那时候的核电站控制系统中，一个软件bug可能导致灾难性后果。我记得读过一个案例：1979年三里岛核事故，部分原因就是控制系统在异常工况下做出了错误响应。
从那以后，工业界开始制定安全相关的标准，比如IEC 61508——这是功能安全的「母标准」，后来汽车、铁路、航空等行业的标准都源于它。
1.3.2 汽车行业：ISO 26262的诞生
汽车行业真正开始重视功能安全，是在2000年代初期。那时候电子系统越来越多，线控油门、ESP、自动变速箱……系统之间互相耦合，一个故障可能引发连锁反应。
2011年，ISO 26262正式发布。这是专门针对汽车电子电气系统的功能安全标准。它把安全等级分为ASIL A、B、C、D四个级别，D级最高。AD系统通常要求ASIL B到ASIL D。
我曾经在一个项目中，负责一个L3级自动驾驶域控制器的功能安全设计。按照ISO 26262的要求，我们做了完整的危害分析和风险评估（HARA），最终确定感知融合模块需要达到ASIL C。说实话，那个过程很痛苦——每个故障模式都要分析，每个安全机制都要验证。但做完之后，整个团队对系统的理解都上了一个台阶。
1.3.3 自动驾驶时代：SOTIF的加入
到了L3级以上，问题变了。很多时候系统没坏，但行为还是危险的——比如前面说的摄像头被强光干扰。这就是「预期功能安全」（SOTIF），对应标准ISO 21448。
SOTIF关注的是：系统在正常工作时，会不会因为性能局限或环境干扰，做出不安全的决策。说白了，就是「系统没坏，但不够聪明」。
我个人的理解是：ISO 26262管的是「硬件/软件故障」，ISO 21448管的是「功能不足/场景局限」。两者合在一起，才构成完整的AD系统安全体系。
注意：很多团队只做了ISO 26262，忽略了SOTIF。结果在真实道路测试中，系统因为传感器性能边界问题频繁触发安全机制，用户体验极差。我建议两个标准一起看，不要偏废。
1.3.4 当前趋势：从标准到实践
现在，功能安全在AD领域已经进入「深水区」。标准越来越细，工具链越来越成熟，但挑战也越来越大：
- AI算法的可解释性：深度学习模型怎么证明它在所有场景下都是安全的？
- 系统级安全：多个ECU、多个传感器、多个执行器，怎么保证整体安全？
- 持续安全：OTA升级后，安全状态怎么验证？
我记得去年参加一个行业会议，有位同行说了一句话让我印象很深：「功能安全不是终点，而是起点。真正的挑战在于，如何在保证安全的同时，让系统足够好用。」
嗯，这句话说得在理。安全不是锁死系统，而是让系统在可控范围内运行。这也是我们这门课要讲的核心——怎么把功能安全真正落地到AD系统中去。
| 阶段 | 时间 | 关键事件/标准 | 对AD的影响 |
|---|---|---|---|
| 工业安全 | 1970s-1990s | IEC 61508 | 奠定安全生命周期概念 |
| 汽车电子 | 2000s-2011 | ISO 26262 发布 | ASIL等级、HARA方法引入 |
| 自动驾驶 | 2016-至今 | ISO 21448 (SOTIF) | 关注功能不足与场景局限 |
| 未来趋势 | 2025+ | AI安全、持续安全 | 可解释性、OTA安全验证 |
一个小建议：如果你刚开始接触功能安全，别急着啃标准原文。先理解「为什么需要安全」和「安全机制怎么保护人」，再去看标准条款，会容易得多。我当年就是先做项目，再读标准，发现很多条款其实都是实践中总结出来的。