3. 危害分析与风险评估(HARA)

HARA，全称 Hazard Analysis and Risk Assessment。说白了，就是给芯片找茬，然后评估这个茬有多严重。

我刚开始做功能安全那会儿，觉得HARA就是个形式化的文档工作。直到有一次，一个客户反馈说我们的SoC在特定工况下会输出错误数据，差点导致车辆误加速。嗯，从那以后，我再也不敢轻视HARA了。

3.1 HARA方法论：从模糊到清晰

HARA的核心思路其实很简单：先想清楚芯片会在什么场景下工作，再想清楚如果出错了会怎样，最后评估这个错误有多危险。

我个人习惯把HARA分成三个步骤：

1. 场景定义：芯片会在什么环境下运行？
2. 危害识别：芯片失效会导致什么危险？
3. 风险定级：这个危险有多大概率发生？后果多严重？

你想想看，这三个步骤其实跟日常生活中的风险评估一模一样。比如过马路，你得先看路况（场景），再想被车撞了会怎样（危害），最后决定要不要走斑马线（风险定级）。

3.2 运行场景定义：别漏掉任何一个角落

运行场景，就是芯片在实际车辆中会经历的各种情况。这里最容易犯的错误是——只考虑正常工况。

我曾经在一个项目中，团队只定义了“车辆正常行驶”的场景。结果芯片在低温启动时出现了时序问题，因为没人想过零下30度时晶振的起振时间会变长。

定义场景时，我建议从以下几个维度入手：

维度	典型场景	为什么重要
环境条件	高温、低温、潮湿、振动	芯片的电气特性会随环境变化
车辆状态	启动、行驶、停车、充电	不同状态下芯片的供电和负载不同
用户操作	正常驾驶、误操作、紧急操作	用户行为会触发不同的系统响应
故障模式	单点故障、多点故障、共因故障	芯片本身也可能出问题

嗯，这里要注意：场景不是越多越好。我见过有人定义了200多个场景，结果大部分都是重复的。我的经验是，每个功能模块定义5-10个典型场景就够了。

3.3 危害事件识别：找到那个“万一”

危害事件，就是芯片失效后，对车辆和人员造成的直接伤害。这里有个容易混淆的概念：危害事件 ≠ 芯片故障。

举个例子：芯片的ADC模块输出错误数据，这是故障。但这个故障导致刹车系统误判了车速，最终造成追尾，这才是危害事件。

识别危害事件时，我习惯用“如果...那么...”的句式来推演：

• 如果芯片输出错误，那么系统会怎样响应？
• 如果系统错误响应，那么车辆会怎样动作？
• 如果车辆异常动作，那么人员会面临什么风险？

3.4 ASIL等级确定：给风险打分

ASIL，全称 Automotive Safety Integrity Level，分为A、B、C、D四个等级，D是最严格的。

确定ASIL等级，ISO26262给出了三个参数：

• S（Severity）：伤害的严重程度。S0（无伤害）到S3（致命伤害）
• E（Exposure）：暴露在危险场景中的概率。E0（几乎不可能）到E4（非常高）
• C（Controllability）：驾驶员或其他人控制风险的能力。C0（完全可控）到C3（几乎不可控）

这三个参数组合起来，就得到了ASIL等级。具体规则如下：

S	E	C	ASIL
S1	E1	C1	A
S2	E2	C2	B
S3	E3	C2	C
S3	E4	C3	D

这里有个坑：ASIL等级不是越高越好。我见过有人把所有功能都定成ASIL D，结果芯片面积翻了一倍，功耗也超标了。实际上，很多功能只需要ASIL A或B就够了。

3.5 HARA的实战输出

HARA做完后，你会得到一份文档，里面包含：

• 每个危害事件的详细描述
• 对应的ASIL等级
• 安全目标（Safety Goal）
• 安全状态（Safe State）

安全目标，就是“芯片必须做什么来避免这个危害”。比如：“ADC模块必须在100ms内检测到输出错误，并切换到安全模式”。

安全状态，就是“芯片进入安全模式后是什么样子”。比如：“ADC输出固定为0，系统使用备用传感器数据”。

我个人习惯在HARA文档里加一个“备注”列，记录一些设计上的考虑。比如：“这个危害事件可以通过硬件冗余来解决，但成本较高，建议用软件监控”。这样后续做架构设计时，就能直接参考。

3.6 知识体系图

下面这张图，是我自己总结的HARA核心逻辑。你可以把它当成一个检查清单，每次做HARA时对照着看。

这张图把HARA的三个核心步骤串起来了。从左到右，从场景到危害再到等级，最后输出文档。中间的虚线箭头表示迭代——你做完一轮后，可能会发现新的场景，那就再跑一轮。

好了，HARA的内容就讲到这里。记住一句话：HARA不是写给别人看的文档，而是帮你发现芯片设计漏洞的工具。认真做，它能帮你省下流片失败的成本；敷衍做，它就是个废纸。