企业官网建设流程全解析

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

系列导航表

一、引言：为什么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不是孤立的活动，它与多个安全活动紧密关联：

1. Item定义：HARA的输入，定义相关项的边界、功能和接口
2. 功能安全概念（FSC）：HARA的输出之一，描述如何实现安全目标
3. 技术安全需求（TSR）：从安全目标导出，是HARA到系统设计的桥梁
4. 安全确认：验证最终产品是否满足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完整流程：五步法详解

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 场景分析的完备性保证

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

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

来源依据：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）：

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

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

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

2.4.1 Severity（严重度S）

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

2.4.2 Exposure（暴露度E）

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

2.4.3 Controllability（可控性C）

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

重要原则：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查表矩阵使用规则

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

2.5.2 ASIL等级含义

来源依据：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：转向助力突然丢失

安全目标：

"当车速>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分析应输出：

1. Item定义文档：明确系统的边界、功能和接口
2. 场景枚举清单：覆盖所有ODD的运行场景
3. 危害事件列表：包含所有识别的危害事件
4. ASIL分配表：每个危害事件对应的ASIL等级
5. 安全目标清单：最高层级的安全要求
6. 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）

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

来源依据：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 核心要点回顾

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

8.2 工程实践建议

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

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

参考文献

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

附录：术语表

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

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

发表日期：2026-06-30

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