2. 功能安全背景:功能安全概述、ASIL等级定义、安全生命周期

2.1 功能安全到底在讲什么?

说实话,我刚入行那会儿,对「功能安全」的理解也很模糊。总觉得它是个高大上的概念,离实际编码很远。后来踩过坑才明白——功能安全,说白了就是一套系统性的方法,用来保证当系统出故障时,不会伤到人。

你想想看,一辆车在高速上跑着,电子助力转向突然失效了,或者刹车系统的信号被干扰了——这些都不是「概率很低」的事。功能安全要做的,就是把这些风险控制在可接受的范围内。

ISO 26262 里对功能安全的定义很严谨:「不存在由电子电气系统故障行为导致的不合理风险」。注意两个关键词:

  • 故障行为——不是正常行为,是系统出错了
  • 不合理风险——不是零风险,而是风险低到可以接受

核心观点:功能安全不是消除所有故障,而是确保故障发生时,系统能安全地降级或进入安全状态。

我在一个 EPS(电动助力转向)项目中就遇到过这种情况。客户要求转向系统在 MCU 死机后,必须在 50ms 内切断助力,让驾驶员还能靠机械连接手动转向。这就是一个典型的安全机制——故障发生了,但风险被控制住了。

2.2 ASIL 等级——风险有多高,安全就得有多强

ASIL(Automotive Safety Integrity Level)是 ISO 26262 里最核心的概念之一。它把安全要求分成了四个等级:A、B、C、D,D 是最严格的。

怎么确定一个功能该定哪个等级?看三个参数:

参数 含义 等级范围
S(Severity) 伤害的严重程度 S0(无伤害)~ S3(致命)
E(Exposure) 危险场景的发生概率 E0(极低)~ E4(极高)
C(Controllability) 驾驶员能否控制局面 C0(可控)~ C3(不可控)

这三个参数组合起来,就得到了 ASIL 等级。举个例子:

  • S3 + E4 + C3 → ASIL D(高速上刹车失效,致命风险)
  • S2 + E3 + C2 → ASIL B(雨刮器失效,风险较低)
  • S1 + E2 + C1 → ASIL A(车内氛围灯故障,基本没风险)
  • 如果三个参数都很低,那就是 QM(Quality Management),按普通质量管理就行

我的经验:很多团队在定 ASIL 等级时容易「往高了定」,觉得越安全越好。其实不对。ASIL D 的开发成本是 ASIL B 的 3~5 倍。我见过一个项目,把车窗防夹功能定成了 ASIL D,结果测试周期翻了一倍,最后发现其实 ASIL B 就够用了。合理评估,别过度设计。

2.3 安全生命周期——从概念到退役,每一步都不能省

ISO 26262 把功能安全的活动组织成了一个「安全生命周期」。它不是一次性的,而是贯穿整个产品开发过程。

我个人习惯把安全生命周期分成三个阶段来理解:

  1. 概念阶段——定义系统、做 HARA、定安全目标
  2. 开发阶段——从系统级到硬件/软件级,逐层实现安全要求
  3. 生产与运维阶段——制造、测试、售后监控

下面这张图是我自己整理的安全生命周期框架,每次做新项目我都会拿出来对照一遍:

ISO 26262 安全生命周期框架 概念阶段 1. 项目定义 2. HARA 分析 3. 安全目标定义 开发阶段 4. 系统级设计 5. 硬件开发 6. 软件开发 生产与运维 7. 生产计划 8. 运行与维护 9. 退役 反馈与持续改进 说明: 安全生命周期不是线性的。每个阶段都可能因为发现新问题而回退到前一个阶段。 比如硬件测试发现某个安全机制不满足 ASIL 要求,就需要回到系统设计阶段重新分配。 安全目标 功能安全概念 技术安全概念 验证与确认 每个阶段都有对应的 ASIL 等级要求,等级越高,流程越严格

2.4 安全生命周期中的关键节点

每个阶段都有一些「必须做」的事情。我列了一个清单,方便你对照检查:

阶段 关键活动 输出物
概念阶段 项目定义、HARA、安全目标定义 HARA 报告、安全目标列表
系统级开发 功能安全概念、系统架构设计 功能安全概念文档、系统 FMEA
硬件开发 硬件安全要求、硬件设计、FMEDA 硬件安全手册、FMEDA 报告
软件开发 软件安全要求、软件架构、单元测试 软件安全手册、测试报告
生产与运维 生产计划、售后监控、故障响应 生产控制计划、现场监控报告

注意:我曾经在一个项目中跳过「概念阶段」的正式评审,直接进入了开发。结果做到一半发现安全目标定义有歧义,导致硬件和软件两边对不上,最后返工了三个月。安全生命周期里的每一步都有它的意义,别图省事。

2.5 为什么安全生命周期这么重要?

说白了,安全生命周期就是给你一个「检查清单」。你不需要每次都从头想该做什么,照着生命周期走一遍,该做的都做了,该留的记录都留了。

而且,ISO 26262 要求所有安全活动都要有可追溯性。什么意思?就是每个安全目标、每个安全机制、每个测试用例,都要能追溯到源头。没有安全生命周期,你根本做不到这一点。

我记得有一次客户审核,对方问:「你们这个安全目标是怎么来的?」我直接翻出 HARA 报告,指着里面的场景编号说:「这个目标来自场景 S3-E4-C3,对应的危险事件是刹车助力失效。」审核员点点头,没再追问。这就是可追溯性的力量。

2.6 本章小结

这一章我们聊了三件事:

  • 功能安全是什么——控制故障风险,不是消灭故障
  • ASIL 等级怎么定——看 Severity、Exposure、Controllability 三个参数
  • 安全生命周期怎么走——从概念到退役,每一步都有明确的活动和输出