3. HARA 分析流程：从项目定义到 ASIL 等级

HARA 分析，说白了就是给系统做一次全面的「风险体检」。很多新手觉得这步就是走个过场，填填表格就完事了。我刚开始做功能安全时也这么想，直到有一次在项目中漏掉了一个关键场景，后期改设计改到崩溃……嗯，从那以后我再也不敢轻视这个流程了。

HARA 的标准流程分为六个步骤，环环相扣。咱们一个一个来看。

3.1 项目定义：搞清楚你在做什么

项目定义是 HARA 的起点。你得先明确：这个系统是干什么的？装在什么车上？有哪些功能？边界在哪里？

我个人习惯用一张表格来梳理项目定义的核心要素：

3.2 功能定义：把功能说清楚

项目定义之后，咱们得把系统的功能掰开揉碎了讲清楚。功能定义不是简单列个功能列表，而是要描述：功能在什么条件下激活？输出什么？故障时会发生什么？

举个例子，EPS 的「提供转向助力」功能，可以这样定义：

• 功能名称：提供转向助力
• 触发条件：驾驶员转动方向盘，车速 < 80 km/h
• 正常行为：电机输出与方向盘扭矩成正比的助力
• 故障行为：助力突然消失 / 助力过大 / 助力方向错误

你想想看，如果功能定义写得不清不楚，后面的危害识别就会像无头苍蝇一样乱撞。我见过不少团队，功能定义就写一行字「提供转向助力」，结果危害分析时漏掉了一大堆场景。

3.3 危害识别：找出所有可能出问题的地方

危害识别，说白了就是「头脑风暴 + 结构化分析」。你得把系统所有可能的故障模式都想一遍，然后判断这些故障会不会导致人身伤害。

常用的方法有：

• 基于功能的安全分析：针对每个功能，问「如果这个功能失效了会怎样？」
• 基于场景的推理：结合车辆的实际运行场景，想象故障发生时的后果
• 参考历史数据：看看同类系统出过哪些问题

我记得有一次做线控制动系统的 HARA，团队一开始列了 50 多个危害，后来一筛选，真正跟安全相关的只有 12 个。剩下的都是「刹车感觉不舒服」「噪音大」这类问题——这些应该交给质量部门，不是功能安全的事。

3.4 危险事件分析：把危害放到场景里看

危害识别出来之后，还得把它放到具体的驾驶场景里去看。同一个危害，在不同的场景下，风险等级可能天差地别。

比如「转向助力突然消失」这个危害：

• 场景 A：车辆在高速公路上直线行驶，车速 120 km/h
• 场景 B：车辆在市区路口转弯，车速 20 km/h
• 场景 C：车辆在停车场低速挪车

这三个场景的风险能一样吗？显然不一样。场景 A 虽然车速高，但直线行驶时驾驶员对转向力的需求不大，风险相对可控；场景 B 转弯时需要助力，突然消失可能导致驾驶员来不及反应，风险更高。

所以，危险事件分析的核心就是：把「危害」和「场景」组合起来，形成一个个具体的「危险事件」。

3.5 风险评估：量化风险等级

有了危险事件，接下来就是给每个事件「打分」。ISO 26262 用三个参数来评估风险：

每个参数都有详细的判定标准。比如严重度 S：

• S0：无伤害
• S1：轻伤（可自行处理）
• S2：重伤（需要医疗救助）
• S3：致命伤

3.6 ASIL 等级确定：查表出结果

S、E、C 三个参数都评完之后，查 ISO 26262 的 ASIL 等级表，就能确定每个危险事件的 ASIL 等级了。

如果 S、E、C 中任意一个为 0，则 QM（质量管理），不需要按功能安全流程开发。

下面这张图把整个 HARA 流程串起来了，你可以对照着看：

你看，整个流程就像一条流水线：从项目定义开始，一步步往下走，最后输出 ASIL 等级。每一步的输出都是下一步的输入，环环相扣。