【FS-04】ASIL等级体系深度解读：从HARA到安全目标的完整流程

FS-04 功能安全ISO26262之危害分析与风险评估（HARA）工程实践深度解析

系列导航表

系列	文章数	状态	专栏
FS功能安全	FS-01~FS-20	进行中	汽车功能安全: ISO26262深入理解
IF芯片	IF-01~IF-14	已完结	英飞凌AURIX实战系列
AP系统	AP-01~AP-15	已完结	AUTOSAR AP实战指南

一、引言：为什么HARA是功能安全的起点

1.1 HARA在安全生命周期中的核心地位

危害分析与风险评估（Hazard Analysis and Risk Assessment，HARA ）是ISO 26262功能安全生命周期的起点和基石。根据ISO 26262-3:2018 Clause 7的定义，HARA是识别和分类相关项危害事件，并制定安全目标的系统性方法。

来源依据：ISO 26262-3:2018 Clause 7.1 "The hazard analysis and risk assessment shall be performed to identify and categorize the hazards of the item."

HARA的输出直接决定了整个产品开发的安全严格程度。从HARA分析中得出的**安全目标（Safety Goals）**是最高层级的安全要求，所有后续的系统设计、硬件开发、软件实现都必须追溯到这些安全目标。

如上图所示，HARA位于概念阶段的起始位置，其输出驱动整个V模型开发流程：

左支（开发）：HARA → 安全目标 → 技术安全需求 → 系统/硬件/软件设计
右支（验证）：每个开发阶段都有对应的验证活动，确保满足安全目标

1.2 HARA与其他安全活动的关系

HARA不是孤立的活动，它与多个安全活动紧密关联：

Item定义：HARA的输入，定义相关项的边界、功能和接口
功能安全概念（FSC）：HARA的输出之一，描述如何实现安全目标
技术安全需求（TSR）：从安全目标导出，是HARA到系统设计的桥梁
安全确认：验证最终产品是否满足HARA阶段制定的安全目标

来源依据：ISO 26262-3:2018 Clause 7.2 "The hazard analysis and risk assessment shall be based on the item definition."

1.3 HARA的核心输出

HARA分析的完整输出包括：

输出工作产品	描述	用途
HARA报告	完整的分析过程和结果文档	安全档案的核心组成部分
危害事件清单	所有识别的危害事件及其属性	后续分析的输入
ASIL分配表	每个危害事件对应的ASIL等级	确定开发严格程度
安全目标	最高层级安全要求	驱动整个产品开发

二、HARA完整流程：五步法详解

2.1 Step 1：Item Definition（相关项定义）

来源依据：ISO 26262-3:2018 Clause 5

Item定义是HARA的输入，必须明确定义相关项的：

边界定义：相关项与外部环境的接口边界
功能定义：相关项应提供的功能
接口定义：与其他相关项的交互接口
法规要求：必须满足的法规标准

2.1.1 Item定义的关键要素

功能描述：

相关项应实现的核心功能
功能的运行条件和约束
功能与用户期望的对应关系

边界定义：

整车层面的边界
与其他ECU的交互边界
与传感器/执行器的接口边界

假设条件：

对驾驶场景的假设
对驾驶员行为的假设
对环境的假设

来源依据：ISO 26262-3:2018 Clause 5.2 "The item definition shall include a description of the boundaries of the item."

2.2 Step 2：场景分析

来源依据：ISO 26262-3:2018 Clause 7.3

场景分析是HARA中最耗时的步骤，需要系统性地枚举所有可能的运行场景。

2.2.1 运行场景（ODD）枚举

运行设计域（Operational Design Domain，ODD）定义了系统工作的条件范围：

场景维度	示例	分析要点
道路类型	高速/城市/乡村/停车场	不同道路的操控特性
环境条件	晴/雨/雪/夜间/白天	对传感器和执行器的影响
交通状况	拥堵/畅通/低速跟随	事故场景的概率分布
驾驶模式	起步/加速/匀速/转向/泊车	不同操作的失效后果

2.2.2 场景分析的完备性保证

为保证场景识别的完备性，建议采用以下方法：

顶部向下法：从整车功能出发，逐步细化到具体场景
底部向上法：从已知的事故数据库和失效模式出发，逆向构建场景
边界分析法：重点关注极端情况和边界条件

来源依据：ISO 26262-3:2018 Clause 7.3.2 "The operational situations shall be identified."

2.3 Step 3：危害识别

来源依据：ISO 26262-3:2018 Clause 7.4

危害识别是将每个运行场景与潜在危害关联的过程。

2.3.1 危害事件的构成要素

一个完整的危害事件描述需要包含：

要素	描述	示例
功能丧失	预期的功能无法实现	转向助力完全丧失
功能过度	功能超过设计范围	转向助力过大
功能误导	提供的功能与预期不符	转向方向与指令相反
功能延迟	功能响应时间超出要求	转向助力响应延迟

2.3.2 失控模式分析

对于每个功能异常，需要分析其对应的失控模式（Loss of Control Mode）：

失控模式	描述	EPS示例
完全丧失	功能完全停止工作	电机完全不输出扭矩
部分丧失	功能部分降低	助力扭矩降低50%
错误激活	不期望的功能被激活	无指令时产生助力
错误输出	输出与预期不符	助力方向相反

2.4 Step 4：风险评估（S/E/C三因子）

来源依据：ISO 26262-3:2018 Clause 7.5

风险评估是HARA的核心步骤，通过三个独立因子量化每个危害事件的风险。

2.4.1 Severity（严重度S）

严重度评估危害事件可能导致的伤害程度：

等级	名称	描述	示例
S0	无伤害	无任何伤害	仪表显示错误
S1	轻伤	轻微伤害，如擦伤	轻微碰撞
S2	严重伤害	需要医疗干预的伤害	骨折
S3	致命伤害	危及生命或永久性伤害	致命伤害

2.4.2 Exposure（暴露度E）

暴露度评估运行场景发生的概率：

等级	名称	发生频率	EPS示例
E0	不可信	几乎不发生	极端环境
E1	极低概率	每年少于1次	深夜山路
E2	低概率	每年1-10次	城市道路
E3	中概率	每月1次或更频繁	高速行驶
E4	高概率	每次行程都可能	泊车操作

2.4.3 Controllability（可控性C）

可控性评估驾驶员避免伤害的能力：

等级	名称	描述	要求
C0	容易可控	任何驾驶员都能轻易控制	无特殊要求
C1	一般可控	大多数驾驶员能够控制	基础安全机制
C2	难以可控	需要特殊技能或注意力	增强安全机制
C3	不可控	驾驶员无法有效控制	最严格安全机制

重要原则：S/E/C三因子必须独立评估，不能相互影响。

来源依据：ISO 26262-3:2018 Clause 7.5.1 "The assessment shall consider the three parameters of severity, exposure and controllability independently."

2.5 Step 5：ASIL确定

来源依据：ISO 26262-3:2018 Clause 7.5 and ISO 26262-9:2018 Clause 4

根据S/E/C三因子的评估结果，通过查表法确定每个危害事件的ASIL等级。

2.5.1 ASIL查表矩阵使用规则

首先根据S值确定表格的起始行
然后根据E值确定列
最终ASIL由S、E、C三者共同决定

2.5.2 ASIL等级含义

ASIL等级	安全要求	开发成本倍数	典型应用
ASIL A	最低	1x	车内娱乐系统
ASIL B	中等	1.5-2x	仪表显示
ASIL C	高	2-3x	发动机控制
ASIL D	最高	3-5x	制动系统、转向系统

来源依据：ISO 26262-9:2018 Clause 4.2 "The ASIL shall be determined by the combination of severity, exposure and controllability."

三、工程实践：EPS电动助力转向HARA分析

3.1 案例背景

以**电动助力转向系统（EPS）**为例，演示完整的HARA分析过程。

来源依据：ISO 26262-3:2018 Clause 7.4.2 "The hazard analysis shall be performed with a systematic approach."

3.2 Item定义

相关项名称：电动助力转向系统（EPS）

功能描述：

通过电机提供转向助力，辅助驾驶员完成转向操作
根据车速和转向扭矩动态调整助力大小
提供主动回正功能

边界定义：

输入：驾驶员转向指令（扭矩传感器）、车速信号
输出：电机助力扭矩
接口：CAN总线（与BCM、ECU通信）

3.3 场景与危害分析

3.4 典型危害事件分析

危害事件H1：转向助力突然丢失

属性	分析
运行场景	车辆行驶中（E4）
失控模式	助力电机完全不工作
严重度	S3（高速时失去助力可能导致严重事故）
可控性	C3（高速时驾驶员难以仅靠机械转向控制车辆）
ASIL	ASIL D

安全目标：

"当车速>10km/h时，检测到助力丢失后200ms内进入安全状态（跛行模式）"

FTTI确定：200ms

来源依据：ISO 26262-3:2018 Clause 9.2 "The safety goals shall define the top-level safety requirements."

3.5 HARA分析的工作产品

完整的EPS HARA分析应输出：

Item定义文档：明确系统的边界、功能和接口
场景枚举清单：覆盖所有ODD的运行场景
危害事件列表：包含所有识别的危害事件
ASIL分配表：每个危害事件对应的ASIL等级
安全目标清单：最高层级的安全要求
FTTI确定记录：故障容错时间间隔

四、HARA常见陷阱与避坑指南

4.1 场景分析不完备

问题表现：

只考虑正常驾驶场景，忽略边界条件
遗漏极端环境条件（暴雨、冰雪）
未考虑驾驶员误操作

解决策略：

参考事故数据库（NHTSA、ETSC）
采用检查清单确保覆盖
引入多方评审

来源依据：ISO 26262-3:2018 Clause 7.3.1 "The operational situations shall consider the reasonably foreseeable misuse."

4.2 ASIL主观降级

问题表现：

工程师为了降低开发成本，人为降低S/E/C评级
缺乏数据支撑的乐观假设
忽视边界情况的严重性

解决策略：

建立明确的评级标准
要求所有评级都有数据支撑
引入独立的安全评审

来源依据：ISO 26262-3:2018 Clause 7.5.2 "The parameters shall be estimated under worst-case conditions."

4.3 安全目标过于笼统

问题表现：

安全目标描述模糊，无法指导后续开发
缺少具体的触发条件和响应时间要求
未定义明确的安全状态

解决策略：

采用SMART原则：Specific/Measurable/Achievable/Relevant/Time-bound
包含具体的性能指标
明确定义安全状态的退出条件

来源依据：ISO 26262-3:2018 Clause 9.2 "The safety goals shall be clearly stated and unambiguous."

4.4 缺乏追溯性

问题表现：

无法追溯危害事件到安全目标
安全目标与后续设计脱节
分析过程文档不完整

解决策略：

建立完整的追溯矩阵
使用需求管理工具（如DOORS、Jira）
保持文档版本控制

五、HARA评审检查清单

5.1 Item定义完整性检查

Item边界是否明确定义？
功能描述是否覆盖所有预期功能？
接口定义是否完整？
法规要求是否识别？
假设条件是否记录？

5.2 场景分析系统性检查

运行场景是否覆盖完整ODD？
驾驶模式是否全部识别？
环境条件是否考虑极端情况？
场景枚举是否有遗漏？
场景组合是否合理？

5.3 危害识别完备性检查

危害事件清单是否完整？
失控模式是否全面？
潜在伤害是否充分评估？
危害分类是否正确？
与其他系统的相互作用是否考虑？

5.4 ASIL评估合理性检查

S/E/C三因子是否独立评估？
评级依据是否有数据支撑？
是否存在主观降级？
ASIL等级是否符合标准矩阵？
决策依据是否充分记录？

5.5 安全目标正确性检查

安全目标是否覆盖所有高ASIL危害？
触发条件是否明确？
响应时间要求是否合理？
安全状态定义是否清晰？
是否与FTTI关联？

六、HARA与其他ISO 26262活动的关系

6.1 HARA → 功能安全概念（FSC）

功能安全概念是将安全目标转化为功能性安全需求的过程：

输入	活动	输出
安全目标	功能安全策略设计	功能安全需求（FSR）
安全目标	安全机制选型	安全机制策略
安全目标	安全状态定义	安全状态定义

来源依据：ISO 26262-3:2018 Clause 9 "The functional safety concept shall specify the functional safety requirements."

6.2 HARA → 技术安全需求（TSR）

技术安全需求是功能安全需求在技术层面的具体化：

复制代码

安全目标（SG） → 功能安全需求（FSR） → 技术安全需求（TSR）
     ↑                                        ↓
     └──────────── 安全验证 ←─────────────────┘

来源依据：ISO 26262-4:2018 Clause 6 "Technical safety requirements shall be derived from the functional safety requirements."

6.3 HARA → 安全确认

安全确认验证最终产品是否满足HARA阶段制定的安全目标：

确认方法	目的	证据类型
整车级测试	验证安全目标在整车环境中实现	测试报告
极端工况测试	验证边界条件下的安全行为	测试报告
残余风险评估	验证残余风险可接受	评估报告

来源依据：ISO 26262-4:2018 Clause 10 "The safety validation shall demonstrate that the safety goals are met."

七、第三版HARA发展趋势

ISO 26262第三版（预计2027年发布）正在讨论HARA的以下改进方向：

7.1 自动驾驶场景下的HARA

挑战：

驾驶员角色从"操作者"变为"监督者"
可控性（C）如何评估？
ODD边界的明确定义

可能的解决方案：

引入新的C评级（系统可控性）
扩展ODD分析方法
纳入SOTIF协同分析

7.2 机器学习在HARA中的应用

自动化场景生成
基于数据的S/E/C评估
危害事件的模式识别

7.3 敏捷开发环境下的HARA

HARA的增量更新机制
Sprint中的HARA维护
安全基线的版本管理

八、总结与展望

8.1 核心要点回顾

HARA是功能安全的起点：所有安全工作的基础
五步法流程：Item定义 → 场景分析 → 危害识别 → 风险评估 → ASIL确定
S/E/C三因子独立评估：确保评估的客观性
安全目标是HARA的核心输出：驱动整个产品开发
完备性是关键挑战：需要系统化的方法和多轮评审

8.2 工程实践建议

阶段	建议
项目启动	尽早启动HARA，避免后期发现重大安全问题
分析过程	保持透明，记录所有假设和决策依据
评审	引入多方评审，确保分析完备性
维护	当Item变更时及时更新HARA

8.3 下一步：从HARA到安全目标

HARA完成后，下一步是FS-05：安全目标与功能安全概念，将HARA输出的安全目标转化为可实现的技术方案。

参考文献

ISO 26262:2018, Road vehicles --- Functional safety, Part 1-12
GB/T 34590-2017, 道路车辆功能安全（国标等同采用）
IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems
NHTSA, Federal Motor Vehicle Safety Standards

附录：术语表

英文术语	中文术语	定义
HARA	危害分析与风险评估	Hazard Analysis and Risk Assessment
ASIL	汽车安全完整性等级	Automotive Safety Integrity Level
Item	相关项	The system that is subject to hazard analysis
Safety Goal	安全目标	Top-level safety requirement derived from HARA
FTTI	故障容错时间间隔	Fault Tolerant Time Interval
ODD	运行设计域	Operational Design Domain
Severity	严重度	Potential harm severity
Exposure	暴露度	Operational situation probability
Controllability	可控性	Ability to avoid harm

本文标签：#功能安全 #ISO26262 #汽车电子 #HARA #危害分析 #风险评估 #AUTOSAR #汽车安全 #功能安全工程 #汽车电子安全

本文来源：原创内容，基于ISO 26262:2018标准原文

发表日期：2026-06-30

系列：FS-04 功能安全ISO26262系列（共20篇）