汽车功能安全【ISO 26262】概述1

1 为什么需要功能安全

任何事物都存在或多或少的缺陷，比如人（理想很丰满，现实很残酷），再比如物（任何事物都存在老化等）。因此，系统失效可以分为以下两类：

• 系统性失效：汽车E/E系统开发过程中（软件和硬件），人都可能不可避免地出现疏忽或者失误，导致系统功能失效，从而产生危害。这类人为疏忽导致地失效未系统性失效。
• 随机硬件失效：随着使用时间的变长，外部环境的影响，控制器硬件都会出现老化或者故障，导致系统功能失效，从而产生危害。硬件失效带有随机性，存在一定概率分布，因此成为硬件随机失效。

为了避免上述两种失效，功能安全的概念就诞生了。

核心目标：防止因电子电气系统失效导致的人身伤害
现实痛点：现代汽车电子化程度高（ECU超100个，代码量超1亿行），任何软件/硬件失效都可能引发事故。
示例：

一辆车的电子助力转向系统（EPS）在高速行驶时突然失效（如软件跑飞）。若无功能安全设计，可能导致方向盘锁死引发车祸；通过ISO 26262设计的系统会检测异常并启动冗余电机或机械备份。

2 功能安全解决什么问题

三类关键问题：

1. 随机硬件失效
   通过对控制器硬件进行概率化度量或者采用冗余设计的安全机制，尽可能地减低随机硬件失效
   问题：芯片老化导致刹车控制模块信号错误
   解决方案：采用双MCU冗余架构（如特斯拉Autopilot的ASIL D设计）

2. 系统性失效
   咱们平常项目质量管理（QM），要求都不是很高。功能安全对汽车E/E系统软硬件全生命周期开发流程、方法等进行了约束和规范，尽可能地降低人为导致的系统性失效。
   问题：自动驾驶代码因边界条件溢出导致误刹车
   解决方案：模型测试覆盖100% MC/DC（修改条件/判定覆盖）

3. 安全机制缺失
   通过设定安全机制和安全状态，当系统出现故障时，在故障容错时间内系统进入安全状态，保证人身、财产安全。
   问题：电池管理系统(BMS)过压时无断电保护
   解决方案：增加独立硬件看门狗+保险丝熔断机制

流程概述如下图：

3 功能安全法规

强制性标准演进：

注：ISO 21448预期功能安全不是本文的重点。

案例：2020年后欧盟新车必须通过ISO 26262认证，否则无法获得E-mark认证

4 功能安全的四大特征

1. 全生命周期管控
   系统、软件以及硬件开发都遵循各自V模型，都从需求到架构再到设计实现，最后验证及其系统确认（确认只有在系统层面）。
   从概念到报废的V模型开发：

2. 量化目标导向

   • 单点故障度量（SPFM）：要求ASIL D≥99%
   • 潜伏故障度量（LFM）：要求ASIL D≥97%

   示例：安全气囊控制器必须达到10 FIT（1 FIT=10亿小时1次失效）

3. ASIL等级分解

   ASIL等级	目标失效概率	应用场景
   D	10^-8/小时	动力转向/制动
   C	10^-7/小时	大灯控制
   B	10^-6/小时	车窗升降

4. 深度防御架构
   典型安全机制：

   • 输入信号校验（如信号合理性检查）
   • 处理层监控（如双核锁步）
   • 执行层保护（如继电器状态回读）

5 功能安全是否必要

必要性证据：

1. 事故避免价值：
   • 博世研究显示，功能安全设计使电子失效事故下降90%+
2. 商业成本对比：

   项目	无功能安全	ASIL D认证
   开发成本	1x	1.3-1.8x
   召回成本	高（如丰田刹车门赔12亿$）	接近0

3. 技术进化刚需：
   • L3+自动驾驶要求故障响应时间 反例警示：2019年某新能源车因BMS未做ASIL C认证，导致充电时高压继电器粘连引发火灾

6 结论

功能安全是汽车电子系统的生存底线，它解决的是电子失效引发的不可接受风险。随着智能化发展，其必要性已从“合规要求”升级为“技术竞争力核心”，既降低企业长期风险，更是对生命的敬畏。