第10章：ASIL等级确定——从HARA到开发实践的完整链路

各位工程师朋友，今天我们来聊聊ASIL等级确定这件事。说实话，这是ISO 26262里最让我头疼，也最让我着迷的部分。为什么？因为它直接决定了你后续所有工作的「用力程度」。

我见过太多项目，前期ASIL定高了，开发团队叫苦连天；定低了，安全评审过不了。嗯，这里面的门道，我今天一次性讲清楚。

10.1 ASIL定义：四个等级，一个QM

ASIL的全称是Automotive Safety Integrity Level，汽车安全完整性等级。说白了，就是告诉你「这个功能出问题会死几个人」。

ISO 26262定义了四个等级：

注意，QM不是安全等级。它只是说「按质量管理体系做就行」。我遇到过有人把QM当成ASIL 0，这是不对的。

10.2 危害分析与风险评估(HARA)——最关键的起点

HARA，全称Hazard Analysis and Risk Assessment。这是ASIL等级确定的唯一依据。没有HARA，你谈ASIL就是空中楼阁。

HARA的核心步骤，我总结为三步：

1. 场景识别：这个功能在什么情况下可能出问题？
2. 危害定义：出问题后会导致什么后果？
3. 等级评定：根据S、E、C三个参数确定ASIL。

举个实际例子。我之前做EPS（电动助力转向）项目，HARA里有一个典型场景：

功能：转向助力
失效模式：助力突然丧失
驾驶场景：高速公路上以120km/h行驶
危害后果：驾驶员需要施加更大的力才能转向，可能引发碰撞
S=3（生命危险），E=4（每次驾驶都暴露），C=3（普通人难以控制）
→ ASIL D

你看，一个简单的助力丧失，因为场景选得「狠」，直接干到D级。这就是HARA的威力。

10.3 ASIL分解——把大石头敲碎

ASIL D的开发成本太高了。怎么办？ISO 26262给了你一条活路——ASIL分解。

分解的核心思想：一个高ASIL的功能，可以由多个低ASIL的组件共同实现。

举个例子：

原始需求：ASIL D
分解方案：
  组件A：ASIL C(D)
  组件B：ASIL C(D)
  冗余设计：两个组件互相监控

注意：分解后的等级要加括号标注原始等级

分解规则很简单：

• ASIL D 可以分解为：D=D+D, D=C+C, D=B+B, D=A+A
• ASIL C 可以分解为：C=C+C, C=B+B, C=A+A
• ASIL B 可以分解为：B=B+B, B=A+A
• ASIL A 可以分解为：A=A+A

但要注意，分解不是万能的。我个人的经验是：

• 分解后每个组件都要独立做安全分析
• 冗余路径之间必须满足「独立性」要求
• 不能把ASIL D分解成四个ASIL A——标准不允许

10.4 ASIL等级对开发的影响——牵一发而动全身

ASIL等级一旦确定，它会影响你开发流程的每一个环节。我列个表，大家感受一下：

你看，从ASIL A到ASIL D，工作量几乎是翻倍增长的。我做过一个统计：

• ASIL A的开发成本大约是QM的1.5倍
• ASIL B是2倍
• ASIL C是3倍
• ASIL D是4-5倍

所以，为什么我前面强调HARA一定要做准？因为ASIL定高了，你烧钱；定低了，你烧命。

10.5 我的实战建议

最后，分享几条我这些年摸爬滚打总结出来的经验：

1. HARA不要一个人做。拉上系统工程师、功能安全工程师、甚至测试一起讨论。不同视角能发现你忽略的场景。
2. ASIL分解要留余量。比如目标ASIL D，我习惯分解成C+C，而不是B+B。为什么？因为万一某个组件没达到预期，还有回旋余地。
3. 文档要写清楚分解理由。评审时最怕听到「我们就是这么分的」。你要能说清楚：为什么这么分？独立性怎么保证？故障检测时间是多少？
4. 工具链要提前评估。ASIL D要求工具置信度TCL3，这意味着你的编译器、静态分析工具都要经过严格鉴定。别等到开发到一半才发现工具不达标。

好了，关于ASIL等级确定，今天就聊到这里。下一章我们讲安全目标与安全状态的定义，那又是另一个有意思的话题。