2. 危害分析与风险评估(HARA):从方法论到落地

HARA,全称 Hazard Analysis and Risk Assessment。说白了,就是回答三个问题:车会不会出危险?出了危险有多严重?我们能不能接受?

我刚开始做功能安全那会儿,总觉得HARA就是走个过场,填几张表就完事了。直到有一次评审,被安全专家问住:“你这个危害事件,在什么场景下发生?驾驶员有没有机会干预?” 嗯,从那以后,我再也不敢小看HARA了。

核心观点: HARA不是文档堆砌,它是后续所有安全活动的“宪法”。ASIL等级定错了,后面的安全机制要么过设计(烧钱),要么欠设计(危险)。

2.1 HARA方法论:三步走

我个人习惯把HARA拆成三个步骤,简单粗暴:

  1. 功能定义 —— 搞清楚系统到底要干什么。
  2. 危害识别 —— 找出功能失效后会出什么事。
  3. 风险评定 —— 给每个危害事件定个“危险等级”。

你想想看,如果连功能都没定义清楚,后面的分析就是空中楼阁。我在项目中遇到过好几次,供应商说“我们做了HARA”,结果一看,连系统边界都没画清楚。这种HARA,你敢信吗?

2.2 危害事件识别:别漏掉“奇葩场景”

危害事件 = 功能失效 + 具体场景。这里有个关键点:场景要具体。

举个例子,电动助力转向系统(EPS)的“转向助力丧失”:

  • 场景A: 车辆在高速公路上以120km/h行驶,驾驶员突然失去助力,需要大力打方向。
  • 场景B: 车辆在停车场以5km/h挪车,驾驶员失去助力,顶多费点力气。

同一个失效,场景不同,风险天差地别。所以,识别危害事件时,我建议你多想想“极端场景”:

避坑指南: 我曾经在做一个ADAS项目时,只考虑了“正常行驶”场景,忽略了“雨雪天气+车道线模糊”的组合。结果HARA评审被打了回来,补了整整一周的场景分析。记住:场景组合越极端,越容易暴露高风险。

2.3 风险等级评定:S、E、C三要素

ISO 26262用三个参数来评定风险等级:

参数 全称 含义 等级范围
S Severity 危害的严重度 S0 ~ S3
E Exposure 场景发生的概率 E0 ~ E4
C Controllability 驾驶员能否控制 C0 ~ C3

最终ASIL等级 = f(S, E, C)。具体查表:

S E C ASIL
S3 E4 C3 ASIL D
S2 E3 C2 ASIL B
S1 E2 C1 ASIL A
S0 任意 任意 QM
注意: 很多人容易把“E”和“C”搞混。E是场景发生的概率(比如“高速行驶”这个场景出现的频率),C是驾驶员能不能躲开危险(比如“突然失去转向助力,驾驶员能不能稳住车”)。E和C是独立的,不要互相影响。

2.4 实战案例:EPS的HARA片段

拿EPS的“非预期转向”来练练手。假设我们识别出这样一个危害事件:

  • 危害事件: 车辆在高速公路上以100km/h行驶,EPS控制器故障导致方向盘突然向右转动10度。
  • S(严重度): 车辆偏离车道,可能撞上护栏或相邻车辆,造成严重伤害 → S3
  • E(暴露率): 高速公路行驶是常见场景,每次开车都可能遇到 → E4
  • C(可控性): 驾驶员在100km/h下突然遭遇非预期转向,很难在瞬间稳住车辆 → C3

查表:S3 + E4 + C3 = ASIL D。这意味着,针对这个危害事件,我们需要设计最高等级的安全机制。

我的经验: 实际项目中,S、E、C的评定往往会有争议。我的建议是:拉上系统、软件、硬件、测试、甚至市场的人一起评审。 一个人拍脑袋定等级,很容易翻车。

2.5 HARA知识体系总览

下面这张图,是我自己总结的HARA核心逻辑。你可以把它当作一个检查清单,做HARA时对照着看,不容易漏项。

HARA知识体系总览 HARA 知识体系总览 1. 功能定义 2. 危害识别 3. 风险评定 功能定义子项 • 系统边界 • 功能清单 • 运行模式 危害识别子项 • 失效模式 • 危害场景 • 危害事件 风险评定子项 • S(严重度) • E(暴露率) • C(可控性) 输出:ASIL 等级(A/B/C/D/QM) 关键原则 1. 每个危害事件独立评定,不合并、不平均 2. 场景要具体,避免“车辆行驶”这种模糊描述

2.6 常见误区与避坑

做HARA这么多年,我踩过不少坑。挑几个典型的说说:

  • 误区一:把“功能失效”直接当成“危害事件”。 比如“转向助力丧失”只是一个失效,不是危害事件。危害事件必须包含场景。
  • 误区二:S、E、C评定过于乐观。 我见过有人把“高速爆胎”的C评为C1,理由是“老司机能稳住”。拜托,ISO 26262考虑的是普通驾驶员,不是赛车手。
  • 误区三:忽略组合危害。 比如“制动失效 + 转向卡死”同时发生。虽然概率低,但一旦发生,后果不堪设想。我个人习惯在HARA中单独列一个“组合危害”章节。
一个小技巧: 做HARA时,准备一个“场景库”。把常见的、极端的、甚至奇葩的场景都列进去。每次新项目,直接从库里挑,再补充新场景。这样既省时间,又不容易漏。

2.7 小结

HARA是功能安全的基石。它不复杂,但需要细心和经验。记住三个关键词:场景、参数、等级。场景要具体,参数要客观,等级要合理。