引言
在汽车功能安全的实施过程中,不同 ASIL 等级要求不同深度和严格程度的分析方法。ISO 26262-9 专门针对 ASIL A、B、C、D 定义了相应的分析方法要求。
想象一个真实场景:某汽车厂商的制动系统,虽然通过了 ASIL B 的 FMEA 分析,但系统仍然发生了严重的安全事故。事后调查发现,原因是 FMEA 分析不够深入,没有考虑某些极端的故障组合场景。
这个案例告诉我们:**ASIL 等级越高,要求的分析越深入、越全面。**这正是 ISO 26262-9 ASIL 导向的分析方法的核心使命。
ASIL 导向分析的目标和范围
ASIL 导向分析的核心活动
ISO 26262-9 定义了针对不同 ASIL 等级的分析要求:
低安全要求] --> FMEA1[FMEA
失效模式分析] ASILB[ASIL B
中低安全要求] --> FMEA2[FMEA] ASILB --> FTA1[FTA
故障树分析] ASILC[ASIL C
中高安全要求] --> FMEA3[FMEA] ASILC --> FTA2[FTA] ASILC --> STPA1[STPA
系统理论分析] ASILD[ASIL D
最高安全要求] --> FMEA4[FMEA] ASILD --> FTA3[FTA] ASILD --> STPA2[STPA] ASILD --> SA[安全分析
Safety Analysis] end style ASILA fill:#34C759,stroke:#34C759,stroke-width:2px,color:#ffffff style ASILB fill:#30D158,stroke:#34C759,stroke-width:2px,color:#ffffff style ASILC fill:#FFCC00,stroke:#FF9500,stroke-width:2px,color:#ffffff style ASILD fill:#FF3B30,stroke:#FF3B30,stroke-width:3px,color:#ffffff style FMEA1 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FMEA2 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FMEA3 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FMEA4 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FTA1 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FTA2 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style FTA3 fill:#5AC8FA,stroke:#007AFF,stroke-width:1px style STPA1 fill:#AF52DE,stroke:#AF52DE,stroke-width:1px style STPA2 fill:#AF52DE,stroke:#AF52DE,stroke-width:1px style SA fill:#FF9500,stroke:#FF9500,stroke-width:2px
ASIL A 分析
- FMEA(失效模式与影响分析)
- 基本的安全性分析
ASIL B 分析
- FMEA
- FTA(故障树分析)
- 基本的安全性分析
ASIL C 分析
- FMEA
- FTA
- STPA(系统理论过程分析)
- 深入的安全性分析
ASIL D 分析
- FMEA
- FTA
- STPA
- 安全分析(Safety Analysis)
- 非常深入的安全性分析
ASIL 导向分析的输入和输出
输入
- 系统架构设计:来自系统级开发
- 硬件架构设计:来自硬件级开发
- 软件架构设计:来自软件级开发
- 安全目标:来自概念阶段
- 功能安全需求:来自概念阶段
输出
- FMEA 报告:失效模式与影响分析报告
- FTA 报告:故障树分析报告
- STPA 报告:系统理论过程分析报告
- 安全分析报告:深入的安全性分析报告
FMEA(失效模式与影响分析)
FMEA 的定义
FMEA(Failure Mode and Effects Analysis) 是一种自底向上的分析方法,用于识别系统组件的潜在失效模式及其影响。
FMEA 的类型
- DFMEA(Design FMEA):设计 FMEA,用于分析设计阶段的失效
- PFMEA(Process FMEA):过程 FMEA,用于分析生产过程的失效
- SFMEA(System FMEA):系统 FMEA,用于分析系统级的失效
FMEA 的步骤
第一步:系统分解
将系统分解为子系统、组件、零件等。
第二步:识别失效模式
识别每个组件的潜在失效模式。
第三步:分析失效影响
分析每个失效模式的局部影响、系统影响、车辆影响、用户影响。
第四步:评估失效严重性(S)
评估失效的严重性等级(1-10)。
第五步:评估失效频度(O)
评估失效发生的频度(1-10)。
第六步:评估失效检测度(D)
评估失效的检测能力(1-10)。
第七步:计算 RPN(风险优先数)
$$ \text{RPN} = S \times O \times D $$
第八步:制定改进措施
针对高 RPN 的失效模式制定改进措施。
案例:制动系统的 FMEA
FMEA 表格:
| 组件 | 失效模式 | 失效原因 | 局部影响 | 系统影响 | 车辆影响 | 用户影响 | S | O | D | RPN |
|---|---|---|---|---|---|---|---|---|---|---|
| 压力传感器 | 开路 | 焊接不良 | 无信号 | 制动失效 | 停车困难 | 难以停车 | 9 | 4 | 5 | 180 |
| 压力传感器 | 短路 | 寄生电容 | 信号错误 | 制动误动作 | 意外制动 | 惊吓 | 7 | 3 | 4 | 84 |
| 压力传感器 | 漂移 | 温度变化 | 测量误差 | 制动不精确 | 制动不均匀 | 制动效果差 | 5 | 6 | 6 | 180 |
| 阀门 | 卡死 | 污染 | 无动作 | 制动失效 | 停车困难 | 难以停车 | 9 | 2 | 4 | 72 |
| 阀门 | 响应慢 | 润滑不良 | 动作延迟 | 制动延迟 | 停车距离增加 | 停车困难 | 7 | 4 | 5 | 140 |
| MCU | CPU 挂死 | 软件缺陷 | 无响应 | 系统失效 | 无助力 | 转向困难 | 8 | 3 | 4 | 96 |
| MCU | Flash 坏块 | 老化 | 数据损坏 | 控制错误 | 制动错误 | 制动效果差 | 6 | 2 | 3 | 36 |
改进措施:
针对 RPN ≥ 100 的失效模式制定改进措施:
| 失效模式 | 改进措施 | 责任人 | 状态 |
|---|---|---|---|
| 压力传感器开路 | 添加冗余传感器 | 硬件设计师 | 已实施 |
| 压力传感器漂移 | 添加温度补偿算法 | 软件设计师 | 已实施 |
| 阀门响应慢 | 改进阀门设计 | 机械设计师 | 计划中 |
| MCU CPU 挂死 | 添加看门狗 | 硬件设计师 | 已实施 |
FTA(故障树分析)
FTA 的定义
FTA(Fault Tree Analysis) 是一种自顶向下的分析方法,用于分析系统失效的原因。
FTA 的步骤
第一步:定义顶层事件
定义要分析的顶层事件(通常是危险事件)。
第二步:构建故障树
使用逻辑门(与门、或门)构建故障树。
第三步:分析最小割集
识别导致顶层事件发生的最小失效组合。
第四步:定性分析
分析失效模式的重要性和影响。
第五步:定量分析
计算顶层事件的发生概率。
FTA 的符号
| 符号 | 名称 | 描述 |
|---|---|---|
| ○ | 基本事件 | 不可再分的失效事件 |
| ◇ | 中间事件 | 逻辑门的输出事件 |
| □ | 顶层事件 | 要分析的顶层失效事件 |
| ◇1 | 与门(AND) | 所有输入都发生,输出才发生 |
| ◇0 | 或门(OR) | 任意输入发生,输出就发生 |
| ○∘ | 转移符号 | 连接到其他故障树 |
案例:制动系统的 FTA
顶层事件:制动失效导致无法停车
故障树:
顶层事件] --> OR{{或门}} OR --> Hydraulic[液压失效] OR --> Electronic[电子失效] Hydraulic --> OR2{{或门}} OR2 --> Master[主缸失效
基本事件] OR2 --> Pipe[管路泄漏
基本事件] Electronic --> CPU[CPU故障
基本事件] style Top fill:#FF3B30,stroke:#FF3B30,stroke-width:3px,color:#ffffff style OR fill:#FF9500,stroke:#FF9500,stroke-width:2px,color:#ffffff style OR2 fill:#FFCC00,stroke:#FF9500,stroke-width:2px,color:#ffffff style Hydraulic fill:#5AC8FA,stroke:#007AFF,stroke-width:2px,color:#ffffff style Electronic fill:#5AC8FA,stroke:#007AFF,stroke-width:2px,color:#ffffff style Master fill:#34C759,stroke:#34C759,stroke-width:2px,color:#ffffff style Pipe fill:#34C759,stroke:#34C759,stroke-width:2px,color:#ffffff style CPU fill:#34C759,stroke:#34C759,stroke-width:2px,color:#ffffff
逻辑表达式:
$$ \text{制动失效} = \text{主缸失效} + \text{管路泄漏} + \text{CPU 故障} $$
最小割集:
- {主缸失效}
- {管路泄漏}
- {CPU 故障}
定量分析:
假设:
- 主缸失效概率:$10^{-6}$
- 管路泄漏概率:$10^{-5}$
- CPU 故障概率:$10^{-4}$
制动失效概率(简化模型,假设失效相互独立): $$ P(\text{制动失效}) = P(\text{主缸失效}) + P(\text{管路泄漏}) + P(\text{CPU 故障}) $$ $$ P(\text{制动失效}) = 10^{-6} + 10^{-5} + 10^{-4} = 1.11 \times 10^{-4} $$
改进措施:
| 失效模式 | 改进措施 | 责任人 | 状态 |
|---|---|---|---|
| 主缸失效 | 改进主缸设计 | 机械设计师 | 已实施 |
| 管路泄漏 | 改进管路连接 | 机械设计师 | 已实施 |
| CPU 故障 | 添加冗余 MCU | 硬件设计师 | 已实施 |
STPA(系统理论过程分析)
STPA 的定义
STPA(System-Theoretic Process Analysis) 是一种基于系统理论的安全分析方法,用于分析系统中的潜在危险状态和导致这些状态的因果因素。
STPA 的步骤
第一步:识别系统危险
识别系统中的所有潜在危险。
第二步:构建控制结构
构建系统的控制结构,识别控制器、执行器、传感器、受控过程。
第三步:识别不安全控制行为(UCAs)
识别所有可能导致系统进入危险状态的控制行为。
第四步:分析导致 UCAs 的原因
分析导致不安全控制行为的原因。
第五步:制定安全约束和缓解措施
制定防止 UCAs 发生的安全约束和缓解措施。
案例:制动系统的 STPA
系统危险:
- 制动助力突然丧失
- 制动力突然增加(误制动)
- 制动力不足
控制结构:
驾驶员
│
┌────────┴────────┐
│ 制动控制器 │
│ │
传感器 执行器
│ │
制动踏板 阀门
│ │
车辆状态 液压系统
不安全控制行为(UCAs):
提供不正确的制动力
- 驾驶员需要制动,系统提供 insufficient 制动力
- 驾驶员不需要制动,系统提供 excessive 制动力
在错误的时间提供制动力
- 在驾驶员未请求时施加制动力
- 在驾驶员请求时延迟提供制动力
制动力持续时间过长或过短
- 制动力持续时间过长,导致车辆失控
- 制动力持续时间过短,制动效果不足
导致 UCAs 的原因:
| UCA | 原因类型 | 具体原因 |
|---|---|---|
| 提供不正确的制动力 | 传感器故障 | 压力传感器开路/短路 |
| 提供不正确的制动力 | 执行器故障 | 阀门卡死/泄漏 |
| 提供不正确的制动力 | 控制器故障 | CPU 挂死/计算错误 |
| 在错误的时间提供制动力 | 通信故障 | CAN 总线延迟/中断 |
| 在错误的时间提供制动力 | 软件缺陷 | 时序错误 |
安全约束和缓解措施:
| UCA | 安全约束 | 缓解措施 |
|---|---|---|
| 提供不正确的制动力 | 系统应准确测量制动踏板位置 | 添加冗余传感器 |
| 提供不正确的制动力 | 系统应准确控制阀门 | 添加阀门位置反馈 |
| 在错误的时间提供制动力 | 系统应实时响应制动请求 | 优化软件时序 |
| 在错误的时间提供制动力 | 系统应可靠通信 | 使用双 CAN 冗余 |
安全分析(Safety Analysis)
安全分析的定义
安全分析 是针对 ASIL D 等级的深入分析方法,包括:
- 安全分析计划:制定安全分析计划
- 安全分析执行:执行安全分析
- 安全分析报告:编写安全分析报告
安全分析的方法
- 定性分析:分析失效模式、影响、原因
- 定量分析:计算失效概率、可靠性指标
- 确定性分析:分析系统的确定性行为
- 随机性分析:分析系统的随机性行为
案例:ASIL D 系统的安全分析
系统:电子驻车制动系统(EPB)
安全分析计划:
| 分析类型 | 分析方法 | 分析对象 | 责任人 | 计划时间 |
|---|---|---|---|---|
| 定性分析 | FMEA | 所有硬件组件 | 硬件设计师 | 2025-02-15 |
| 定性分析 | FTA | 系统失效 | 系统架构师 | 2025-02-20 |
| 定量分析 | 可靠性分析 | 系统 | 可靠性工程师 | 2025-02-25 |
| 确定性分析 | STPA | 控制系统 | 软件设计师 | 2025-02-28 |
| 随机性分析 | 蒙特卡洛仿真 | 系统 | 仿真工程师 | 2025-03-05 |
定量分析:
假设 EPB 系统由以下组件组成:
| 组件 | FIT 率 | 冗余度 |
|---|---|---|
| MCU1 | 50 | 无 |
| MCU2 | 50 | 有 |
| 电机驱动器 | 30 | 有 |
| 角度传感器 | 20 | 有 |
| 阀门 | 10 | 有 |
系统 FIT 率计算:
对于三模冗余的 MCU 系统:
假设单个 MCU 的可靠度为 $R = 0.9999$(在任务时间内)。
系统可靠度: $$ R_{\text{system}} = R^3 + 3 \times R^2 \times (1-R) $$ $$ R_{\text{system}} = 0.99999997 $$
失效概率: $$ P(\text{失效}) = 1 - R_{\text{system}} = 1 - 0.99999997 = 3 \times 10^{-8} $$
转换为 FIT 率: $$ \text{FIT} = \frac{P(\text{失效})}{\text{任务时间}} \times 10^9 $$ $$ \text{FIT} = \frac{3 \times 10^{-8}}{1 \text{ 小时}} \times 10^9 = 0.03 \text{ FIT} $$
结论:
- 通过三模冗余,系统的 FIT 率从 50 降低到 0.03
- 满足 ASIL D 的要求
ASIL 导向分析的差异
ASIL A 分析
要求:
- 基本的 FMEA
- 基本的安全性分析
特点:
- 分析深度较浅
- 分析范围较窄
- 重点识别主要失效模式
示例:
- 简单的 FMEA 表格
- 识别主要失效模式
- 制定基本改进措施
ASIL B 分析
要求:
- 详细的 FMEA
- FTA
- 基本的安全性分析
特点:
- 分析深度中等
- 分析范围中等
- 重点识别主要失效模式和失效组合
示例:
- 详细的 FMEA 表格
- 构建 FTA 故障树
- 识别最小割集
- 制定改进措施
ASIL C 分析
要求:
- 详细的 FMEA
- 详细的 FTA
- STPA
- 深入的安全性分析
特点:
- 分析深度较深
- 分析范围较广
- 重点关注失效组合、控制行为
示例:
- 详细的 FMEA 表格
- 详细的 FTA 故障树
- STPA 分析
- 分析导致 UCAs 的原因
- 制定详细安全约束
ASIL D 分析
要求:
- 非常详细的 FMEA
- 非常详细的 FTA
- STPA
- 安全分析(包括定性、定量、确定性、随机性分析)
特点:
- 分析深度非常深
- 分析范围非常广
- 重点关注所有可能的失效模式、失效组合、控制行为、随机性
示例:
- 非常详细的 FMEA 表格
- 非常详细的 FTA 故障树
- STPA 分析
- 定量分析(可靠性、失效概率)
- 确定性分析(控制行为)
- 随机性分析(蒙特卡洛仿真)
- 制定全面安全措施
实战案例:AEB 系统的 ASIL D 分析
让我们以一个实际项目为例,展示 ASIL D 系统的完整分析流程。
项目背景
某汽车厂商正在开发 AEB 系统,用于在检测到碰撞风险时自动施加制动。ASIL 等级:D。
第一步:FMEA 分析
系统组件:
| 组件 | 失效模式 | 失效原因 | 局部影响 | 系统影响 | 车辆影响 | 用户影响 | S | O | D | RPN |
|---|---|---|---|---|---|---|---|---|---|---|
| 摄像头 | 图像模糊 | 镜头污染 | 识别错误 | 判断错误 | 未制动 | 碰撞风险 | 9 | 4 | 3 | 108 |
| 摄像头 | 帧率下降 | 算法复杂度高 | 识别延迟 | 制动延迟 | 停车距离增加 | 碰撞风险 | 8 | 3 | 4 | 96 |
| 雷达 | 信号丢失 | 干扰 | 无数据 | 判断错误 | 未制动 | 碰撞风险 | 9 | 2 | 3 | 54 |
| 雷达 | 距离误差 | 温度变化 | 测量误差 | 判断错误 | 制动不精确 | 制动效果差 | 6 | 5 | 4 | 120 |
| 超声波传感器 | 信号丢失 | 污染 | 无数据 | 判断错误 | 未制动 | 碰撞风险 | 7 | 3 | 3 | 63 |
| 雷达 | 距离误差 | 温度变化 | 测量误差 | 判断错误 | 制动不精确 | 制动效果差 | 6 | 5 | 4 | 120 |
| MCU | CPU 挂死 | 软件缺陷 | 无响应 | 系统失效 | 无 AEB | 碰撞风险 | 9 | 2 | 3 | 54 |
| MCU | 算法错误 | 软件缺陷 | 计算错误 | 判断错误 | 误制动/未制动 | 碰撞风险/误制动 | 9 | 2 | 4 | 72 |
改进措施:
针对 RPN ≥ 100 的失效模式制定改进措施:
| 失效模式 | 改进措施 | 责任人 | 状态 |
|---|---|---|---|
| 摄像头图像模糊 | 添加自动清洁功能 | 光学设计师 | 已实施 |
| 雷达距离误差 | 添加温度补偿算法 | 软件设计师 | 已实施 |
| 雷达距离误差 | 优化雷达设计 | 射频设计师 | 计划中 |
第二步:FTA 分析
顶层事件:AEB 失效导致碰撞
故障树:
AEB 失效
│
┌────┴────┐
│ │
传感器失效 控制器失效
│ │
┌───┴───┐ ┌─┴────┐
│ │ │ │
摄像头故障 雷达故障 CPU故障 算法错误
│ │ │ │
○ ○ ○ ○
逻辑表达式:
$$ \text{AEB 失效} = \text{摄像头故障} + \text{雷达故障} + \text{CPU 故障} + \text{算法错误} $$
最小割集:
- {摄像头故障}
- {雷达故障}
- {CPU 故障}
- {算法错误}
定量分析:
假设:
- 摄像头故障概率:$10^{-5}$
- 雷达故障概率:$10^{-5}$
- CPU 故障概率:$10^{-6}$
- 算法错误概率:$10^{-6}$
AEB 失效概率(简化模型): $$ P(\text{AEB 失效}) = 10^{-5} + 10^{-5} + 10^{-6} + 10^{-6} = 2.2 \times 10^{-5} $$
改进措施:
| 失效模式 | 改进措施 | 责任人 | 状态 |
|---|---|---|---|
| 摄像头故障 | 添加冗余摄像头 | 硬件设计师 | 已实施 |
| 雷达故障 | 添加冗余雷达 | 硬件设计师 | 已实施 |
第三步:STPA 分析
系统危险:
- 未能检测到碰撞风险
- 误判碰撞风险
- 制动力不足
- 制动力过大
- 制动时机不当
控制结构:
驾驶员
│
┌────────┴────────┐
│ AEB 控制器 │
│ │
传感器 执行器
│ │
摄像头/雷达/超声波 制动系统
│ │
车辆环境 车辆状态
不安全控制行为(UCAs):
未能提供制动力
- 检测到碰撞风险,但未提供制动力
提供错误的制动力
- 未检测到碰撞风险,但提供了制动力(误制动)
- 检测到碰撞风险,但提供了 insufficient 制动力
- 检测到碰撞风险,但提供了 excessive 制动力
在错误的时间提供制动力
- 制动过晚,导致碰撞
- 制动过早,导致误制动
导致 UCAs 的原因:
| UCA | 原因类型 | 具体原因 |
|---|---|---|
| 未能提供制动力 | 传感器故障 | 摄像头/雷达/超声波传感器故障 |
| 未能提供制动力 | 控制器故障 | CPU 挂死/算法错误 |
| 未能提供制动力 | 执行器故障 | 制动系统故障 |
| 提供错误的制动力 | 传感器误差 | 测量误差/漂移 |
| 提供错误的制动力 | 算法错误 | 碰撞判断错误 |
| 提供错误的制动力 | 控制器故障 | CPU 错误 |
| 在错误的时间提供制动力 | 软件缺陷 | 时序错误 |
| 在错误的时间提供制动力 | 通信故障 | 延迟/中断 |
安全约束和缓解措施:
| UCA | 安全约束 | 缓解措施 |
|---|---|---|
| 未能提供制动力 | 系统应准确检测碰撞风险 | 多传感器融合 |
| 未能提供制动力 | 系统应可靠控制制动 | 冗余控制器 |
| 提供错误的制动力 | 系统应准确测量障碍物 | 多传感器交叉验证 |
| 提供错误的制动力 | 系统应准确判断碰撞 | 优化算法 |
| 在错误的时间提供制动力 | 系统应实时响应 | 优化软件时序 |
| 在错误的时间提供制动力 | 系统应可靠通信 | 双 CAN 冗余 |
第四步:定量分析
系统 FIT 率计算:
| 组件 | FIT 率 | 冗余度 | 有效 FIT 率 |
|---|---|---|---|
| 摄像头 | 20 | 有 | 0.4 |
| 雷达 | 20 | 有 | 0.4 |
| 超声波传感器 | 10 | 有 | 0.2 |
| MCU1 | 50 | 无 | 50 |
| MCU2 | 50 | 有 | 0.25 |
| 制动系统 | 30 | 有 | 0.9 |
总 FIT 率: $$ \text{FIT}_{\text{total}} = 0.4 + 0.4 + 0.2 + 50 + 0.25 + 0.9 = 52.15 \text{ FIT} $$
转换为每小时失效概率: $$ \text{Failure Rate} = \frac{52.15}{10^9} = 5.215 \times 10^{-8} \text{ 每小时} $$
满足 ASIL D 要求:
- ASIL D 要求系统 FIT 率 < 10 FIT
- 当前系统 FIT 率 52.15 FIT,不满足
改进措施:
- 添加 MCU 冗余(三模冗余)
- 优化 MCU 软件,降低 FIT 率
改进后:
- MCU 三模冗余,有效 FIT 率:0.005 FIT
- 总 FIT 率:2.155 FIT
- 满足 ASIL D 要求
常见错误和最佳实践
常见错误
分析深度不足
- ASIL D 系统只做 FMEA
- 忽视 FTA 或 STPA
分析方法不当
- 选择的分析方法不适用于系统
- 分析方法应用不当
分析不完整
- 未识别所有失效模式
- 未考虑失效组合
- 未考虑极端情况
改进措施不落实
- 分析后不制定改进措施
- 改进措施不落实
最佳实践
根据 ASIL 等级选择分析方法
- ASIL A:基本的 FMEA
- ASIL B:FMEA + FTA
- ASIL C:FMEA + FTA + STPA
- ASIL D:FMEA + FTA + STPA + 安全分析
深入分析,不要停留在表面
- 识别所有失效模式
- 考虑失效组合
- 考虑极端情况
使用专业的分析工具
- FMEA 工具(如 Xfmea、APIS IQ-RM)
- FTA 工具(如 Isograph Reliability Workbench)
- STPA 工具(如 STPA Suite)
定期回顾和更新分析
- 系统变更后重新分析
- 运行数据更新分析
- 事故调查更新分析
总结
ISO 26262-9 ASIL 导向的分析方法提供了针对不同 ASIL 等级的分析要求。通过本文的深入解读和丰富的案例实践,我们掌握了:
FMEA(失效模式与影响分析):
- FMEA 的定义和步骤
- 制动系统的 FMEA 实践
FTA(故障树分析):
- FTA 的定义和步骤
- FTA 的符号
- 制动系统的 FTA 实践
STPA(系统理论过程分析):
- STPA 的定义和步骤
- 不安全控制行为(UCAs)
- 制动系统的 STPA 实践
安全分析:
- 安全分析的分类
- 定性分析和定量分析
- ASIL D 系统的安全分析实践
ASIL 导向分析的差异:
- ASIL A/B/C/D 的分析要求
- 不同 ASIL 等级的分析深度
实战案例:
- AEB 系统 ASIL D 分析完整实践
核心要点:
- ASIL 等级越高,要求的分析越深入、越全面
- FMEA 是自底向上的分析,FTA 是自顶向下的分析,STPA 是基于系统理论的分析
- 分析必须深入,不能停留在表面
- 改进措施必须落实,不能只分析不改进
- 定期回顾和更新分析,保持分析的有效性
在下一篇文章中,我们将深入解读 ISO 26262-10 指南部分,学习如何应用 ISO 26262 标准的具体指南。
