1. 功能安全概述：什么是功能安全？为什么需要功能安全？功能安全标准ISO 26262简介

大家好，我是老张。做功能安全这行十几年了，今天咱们聊聊最基础的问题——功能安全到底是什么？

说实话，我刚入行那会儿，也以为功能安全就是「别让车出事故」。后来踩了不少坑才明白，这个理解太片面了。咱们今天就把这事儿掰扯清楚。

1.1 什么是功能安全？

先给个官方定义：功能安全是指系统在出现随机硬件失效或系统失效时，仍然能维持安全状态的能力。

嗯，这句话有点绕。我换个说法：

你想想看，一辆车在路上跑，电子系统随时可能出故障。比如刹车踏板传感器突然坏了，或者ADAS摄像头被泥巴糊住了。功能安全要做的，就是当这些故障发生时，系统能「优雅地」进入安全状态，而不是直接失控。

我在项目中遇到过一件事，印象特别深。有个客户说他们的EPS（电动助力转向）系统，只要电机驱动芯片一坏，方向盘就完全锁死。我说这哪行？功能安全要求的是「降级运行」或者「安全关闭」，不是「直接要命」。后来我们加了一路冗余的扭矩传感器，故障时至少能保证基本转向力。这就是功能安全的典型应用。

1.2 为什么需要功能安全？

这个问题其实挺有意思的。有人问我：「老张，以前的车没有功能安全不也跑得好好的？」

对，但那是以前。现在的车是什么情况？

• 电子系统越来越多：一辆高端车有上百个ECU，几千万行代码
• 功能越来越复杂：自动驾驶、线控转向、线控制动，都是人命关天的功能
• 系统之间耦合紧密：一个传感器坏了，可能引发连锁反应

说白了，传统机械系统失效是「慢动作」——刹车油管漏了，你还能感觉到踏板变软。但电子系统失效是「瞬间的」——芯片逻辑翻转一下，可能0.1秒内就做出错误决策。

我记得2018年有个项目，客户做的是自动泊车系统。他们觉得功能安全是「额外成本」，想省掉。结果测试时，超声波传感器因为温度漂移误报，系统以为有障碍物，直接急刹车。后车追尾了。嗯，从那以后，他们再也不敢省功能安全的预算了。

1.3 功能安全标准ISO 26262简介

说到功能安全，就绕不开ISO 26262。这个标准是汽车行业的「安全圣经」。我建议每个做汽车电子的工程师，至少把它的框架搞清楚。

1.3.1 ISO 26262是什么？

ISO 26262的全称是「道路车辆功能安全标准」。它最早在2011年发布，2018年出了第二版。这个标准覆盖了从概念设计到生产、运营、报废的全生命周期。

它的核心思想是：风险越高，要求越严。

怎么衡量风险？标准引入了ASIL（汽车安全完整性等级）的概念。ASIL分为四个等级：

ASIL等级	风险程度	典型应用
ASIL A	低	后雾灯控制
ASIL B	中	雨刮器控制
ASIL C	高	自适应巡航
ASIL D	最高	制动系统、转向系统

1.3.2 ISO 26262的核心要求

标准把功能安全的要求分成了几个部分：

1. Part 2：管理——安全文化、项目计划、评审流程
2. Part 3：概念阶段——危害分析、风险评估、安全目标
3. Part 4：系统层面——系统架构、安全机制、验证确认
4. Part 5：硬件层面——硬件设计、随机失效度量、硬件集成测试
5. Part 6：软件层面——软件架构、单元测试、集成测试
6. Part 7：生产运营——生产流程、售后监控

我个人习惯把Part 5和Part 6放在一起看。为什么？因为硬件和软件的安全机制是相互配合的。比如硬件检测到电压异常，软件要负责执行降级策略。你光看硬件或者光看软件，都看不全。

1.3.3 随机失效 vs 系统失效

这是ISO 26262里特别强调的两个概念：

• 随机硬件失效：芯片老化、电压波动、电磁干扰导致的「偶然性」故障。比如SRAM的位翻转，概率可以算出来。
• 系统失效：设计错误、需求遗漏、软件bug导致的「确定性」故障。比如你代码里写了个死循环，每次跑到那里都会卡住。

我曾经犯过一个错。有个项目做BMS（电池管理系统），我们花了很多精力算硬件的随机失效率，结果忽略了软件里的一个逻辑错误——当电池温度超过阈值时，软件应该先降流再报警，但我们写反了，先报警再降流。结果测试时，报警弹窗卡住了主线程，降流指令根本没发出去。嗯，这就是典型的系统失效。

1.4 小结

好了，咱们把第一章的核心内容捋一捋：

• 功能安全不是防止故障，而是确保故障时系统安全
• 汽车电子越复杂，功能安全越重要
• ISO 26262是行业标准，核心是「风险越高，要求越严」
• 随机失效和系统失效是两种不同的敌人，应对策略也不同

下一章咱们会深入聊硬件随机失效的具体应对方法，包括怎么算失效率、怎么设计诊断覆盖率。到时候我会拿几个实际项目的案例出来，保证干货满满。

我是老张，咱们下章见。