4. 危害识别方法:系统级危害的识别、基于功能失效的危害分析、头脑风暴与检查表法

危害识别,说白了就是回答一个问题:这辆车在什么情况下会伤人?

我见过不少团队,一上来就埋头写 HARA 表格,结果漏掉了一大半关键场景。为什么?因为脑子里没有一套系统化的方法。今天我们就来聊聊三种最实用的识别手段。

4.1 系统级危害的识别

系统级危害,指的是整车或子系统层面,直接与人员伤害挂钩的危险事件。比如“车辆非预期加速”、“制动助力丧失”、“转向卡滞”。

我个人习惯把系统级危害分成三类:

类别 典型示例 关注点
运动类危害 非预期加速、制动不足、转向失控 车辆动力学边界
感知类危害 驾驶员视野遮挡、信号灯误判 人机交互与感知
能量类危害 高压触电、电池热失控、燃油泄漏 能量存储与释放

识别系统级危害时,我建议你从车辆运行场景出发。比如:

  • 正常驾驶场景(巡航、转弯、制动)
  • 故障场景(传感器失效、通信中断)
  • 环境场景(雨雪、夜间、隧道)
  • 维护场景(充电、检修、拖车)
我的经验: 有一次做 EPS(电动助力转向)项目,团队只考虑了“转向助力丧失”这一个危害。结果在实车测试时发现,“非预期转向助力输出” 才是更危险的场景——方向盘突然自己打过去,驾驶员根本来不及反应。从那以后,我每次都会把“功能过度”和“功能不足”都列出来。

4.2 基于功能失效的危害分析

这个方法的核心逻辑很简单:功能失效 → 系统行为异常 → 危害事件。

具体怎么做?我一般分三步走:

  1. 列出所有功能:把系统提供的每一项功能写清楚。比如 ACC(自适应巡航)有“定速巡航”、“跟车行驶”、“减速停车”等功能。
  2. 分析失效模式:对每个功能,问自己“如果这个功能出问题了,会怎样?”常见的失效模式包括:
    • 功能丧失(该动的时候不动)
    • 功能误触发(不该动的时候动了)
    • 功能输出错误(动了但动错了)
    • 功能时序错误(动早了或动晚了)
  3. 推导危害事件:把失效模式放到具体场景中,看是否会导致人员伤害。

举个例子,ACC 的“跟车行驶”功能:

失效模式 场景 危害事件
跟车功能丧失 高速行驶,前车减速 追尾碰撞
跟车功能误触发 无前车时突然制动 后车追尾
跟车距离计算错误 跟车距离过近 制动不及导致碰撞
注意: 功能失效分析很容易陷入“技术细节”的泥潭。我曾经见过一个团队,花了整整两天讨论某个传感器的内部故障模式,结果连最基本的系统级危害都没列全。记住,先抓大放小,先系统后部件。

4.3 头脑风暴与检查表法

这两种方法,一个靠发散,一个靠收敛。配合使用效果最好。

4.3.1 头脑风暴

头脑风暴不是一群人瞎聊。我主持过几十场危害识别头脑风暴,总结了几条铁律:

  • 跨职能参与:系统工程师、软件工程师、硬件工程师、测试工程师、安全工程师,一个都不能少。
  • 场景驱动:不要空想“可能有什么危害”,而是先定义场景,再问“在这个场景下,系统出问题会怎样?”
  • 鼓励“离谱”的想法:有些危害看起来概率极低,但一旦发生就是灾难。比如“方向盘脱落”——虽然概率低,但后果严重。
  • 记录所有想法:不要当场评判,先记下来再说。
避坑指南: 我曾经主持过一次头脑风暴,团队里有个资深工程师,每次别人提一个想法他就说“这个不可能”。结果半小时后,大家都不说话了。后来我定了个规矩:前30分钟只记录,不评判。效果立竿见影。

4.3.2 检查表法

检查表是头脑风暴的“补丁”。你不可能每次都把所有人聚在一起,但检查表可以随时用。

我常用的检查表包含以下几类:

  • 通用危害清单:加速、制动、转向、视野、警示、能量等
  • 功能特定清单:针对具体功能(如自动泊车、车道保持)的已知危害
  • 场景特定清单:高速、低速、倒车、充电、维修等场景下的危害
  • 历史问题清单:从以往项目、召回案例、事故报告中提取的危害

下面这张图展示了危害识别的整体流程:

危害识别方法体系 系统级危害识别 功能失效分析 头脑风暴+检查表 系统级危害分类 • 运动类:加速/制动/转向 • 感知类:视野/信号/交互 • 能量类:高压/热失控/泄漏 失效模式分类 • 功能丧失 • 功能误触发 • 功能输出错误/时序错误 检查表分类 • 通用危害清单 • 功能特定清单 • 场景/历史问题清单 危害事件清单 三种方法互补使用:系统级识别定方向,功能失效分析挖细节,头脑风暴+检查表查漏补缺

4.4 三种方法的配合使用

你可能会问:这三种方法到底怎么选?我的建议是:全都要。

在实际项目中,我通常这样安排:

  1. 第一步:系统级危害识别(1-2天)—— 先拉通整车级和子系统级的危害,确定分析范围。
  2. 第二步:功能失效分析(2-3天)—— 对每个关键功能,逐条分析失效模式,推导危害事件。
  3. 第三步:头脑风暴 + 检查表(半天到1天)—— 查漏补缺,补充遗漏的场景和危害。
关键提醒: 危害识别不是一次性工作。随着项目推进,你会发现新的场景、新的失效模式。我建议在每个开发阶段(概念、系统设计、软硬件开发)结束时,回头再过一遍危害清单。别等到最后才发现漏了东西,那时候改起来成本就高了。

嗯,以上就是危害识别的三种核心方法。记住,方法只是工具,真正重要的是你脑子里有没有“安全第一”这根弦。下次做 HARA 之前,先把今天讲的这三招用起来,你会发现漏掉的危害少了很多。