汽车功能安全【ISO 26262】概述1
文章目录
- 1 为什么需要功能安全
- 2 功能安全解决什么问题
- 3 功能安全法规
- 4 功能安全的四大特征
- 5 功能安全是否必要
- 6 结论
1 为什么需要功能安全
任何事物都存在或多或少的缺陷，比如人（理想很丰满，现实很残酷），再比如物（任何事物都存在老化等）。因此，系统失效可以分为以下两类：
- 系统性失效：汽车E/E系统开发过程中（软件和硬件），人都可能不可避免地出现疏忽或者失误，导致系统功能失效，从而产生危害。这类人为疏忽导致地失效未系统性失效。
- 随机硬件失效：随着使用时间的变长，外部环境的影响，控制器硬件都会出现老化或者故障，导致系统功能失效，从而产生危害。硬件失效带有随机性，存在一定概率分布，因此成为硬件随机失效。
为了避免上述两种失效，功能安全的概念就诞生了。
核心目标：防止因电子电气系统失效导致的人身伤害
现实痛点：现代汽车电子化程度高（ECU超100个，代码量超1亿行），任何软件/硬件失效都可能引发事故。
示例：
一辆车的电子助力转向系统（EPS）在高速行驶时突然失效（如软件跑飞）。若无功能安全设计，可能导致方向盘锁死引发车祸；通过ISO 26262设计的系统会检测异常并启动冗余电机或机械备份。
2 功能安全解决什么问题
三类关键问题：
-
随机硬件失效
通过对控制器硬件进行概率化度量或者采用冗余设计的安全机制，尽可能地减低随机硬件失效
问题：芯片老化导致刹车控制模块信号错误
解决方案：采用双MCU冗余架构（如特斯拉Autopilot的ASIL D设计） -
系统性失效
咱们平常项目质量管理（QM），要求都不是很高。功能安全对汽车E/E系统软硬件全生命周期开发流程、方法等进行了约束和规范，尽可能地降低人为导致的系统性失效。
问题：自动驾驶代码因边界条件溢出导致误刹车
解决方案：模型测试覆盖100% MC/DC（修改条件/判定覆盖） -
安全机制缺失
通过设定安全机制和安全状态，当系统出现故障时，在故障容错时间内系统进入安全状态，保证人身、财产安全。
问题：电池管理系统(BMS)过压时无断电保护
解决方案：增加独立硬件看门狗+保险丝熔断机制
流程概述如下图：
3 功能安全法规
强制性标准演进：
| 版本 | 覆盖范围 | 法律效力 | 典型地区 |
|---|---|---|---|
| ISO 26262:2011 | 乘用车EE系统 | 准强制（欧盟/中国） | UNECE WP.29 |
| ISO 26262:2018 | 新增卡车/摩托车 | 多国型式认证要求 | 欧盟/日本 |
| ISO 21448(SOTIF) | 预期功能安全 | 自动驾驶必备 | 全球 |
注：ISO 21448预期功能安全不是本文的重点。
案例：2020年后欧盟新车必须通过ISO 26262认证，否则无法获得E-mark认证
4 功能安全的四大特征
-
全生命周期管控
系统、软件以及硬件开发都遵循各自V模型，都从需求到架构再到设计实现，最后验证及其系统确认（确认只有在系统层面）。
从概念到报废的V模型开发： -
量化目标导向
- 单点故障度量（SPFM）：要求ASIL D≥99%
- 潜伏故障度量（LFM）：要求ASIL D≥97%
示例：安全气囊控制器必须达到10 FIT（1 FIT=10亿小时1次失效）
-
ASIL等级分解
ASIL等级 目标失效概率 应用场景 D 10^-8/小时 动力转向/制动 C 10^-7/小时 大灯控制 B 10^-6/小时 车窗升降 -
深度防御架构
典型安全机制：- 输入信号校验（如信号合理性检查）
- 处理层监控（如双核锁步）
- 执行层保护（如继电器状态回读）
5 功能安全是否必要
必要性证据：
- 事故避免价值：
- 博世研究显示，功能安全设计使电子失效事故下降90%+
- 商业成本对比：
项目 无功能安全 ASIL D认证 开发成本 1x 1.3-1.8x 召回成本 高（如丰田刹车门赔12亿$） 接近0 - 技术进化刚需：
- L3+自动驾驶要求故障响应时间 反例警示：2019年某新能源车因BMS未做ASIL C认证，导致充电时高压继电器粘连引发火灾
6 结论
功能安全是汽车电子系统的生存底线，它解决的是电子失效引发的不可接受风险。随着智能化发展，其必要性已从“合规要求”升级为“技术竞争力核心”，既降低企业长期风险，更是对生命的敬畏。