functional-safety-analysis

name	functional-safety-analysis
description	功能安全分析技能 - FMEDA 分析、安全机制设计、ISO 26262 符合
description.zh	功能安全分析技能 - FMEDA 分析、安全机制设计、ISO 26262 符合
origin	ICER
categories	functional-safety

功能安全分析技能

当用户需要进行功能安全分析和安全机制设计时，启用此技能。符合 ISO 26262 标准，支持 ASIL A-D 各个等级。

When to Activate

• 项目开始安全需求分解
• 模块级 FMEDA 分析
• 安全机制设计
• 故障注入测试规划
• 功能安全验证规划
• 文档整理符合 ISO 26262

---

行业经验数值

ASIL 等级要求

ASIL	SPFM	LFM	PMHF	系统能力	硬件指标要求
QM	-	-	-	无要求	无
ASIL-A	≥90%	≥60%	<1000 FIT	低	单点故障诊断
ASIL-B	≥90%	≥60%	<100 FIT	中	诊断+冗余
ASIL-C	≥97%	≥80%	<100 FIT	高	诊断+冗余+监控
ASIL-D	≥99%	≥90%	<10 FIT	最高	全面安全机制

典型 FIT 值参考

组件	典型 FIT	说明
CPU 核心	50-200 FIT	取决于工艺和复杂度
SRAM (per Mb)	10-50 FIT	带 ECC 可降低
Flash (per Mb)	20-100 FIT	取决于工艺
CAN 控制器	5-20 FIT	相对可靠
ADC	5-15 FIT	取决于精度
时钟 PLL	10-30 FIT	关键组件
电源管理	20-50 FIT	需要监控

安全机制诊断覆盖率

安全机制	单点故障覆盖率	潜伏故障覆盖率	适用场景
ECC	90-99%	90-95%	存储器
奇偶校验	50-90%	不适用	简单存储器
CRC	90-99%	不适用	数据传输
双核锁步	90-99%	90-99%	CPU
看门狗	60-90%	60-90%	程序流
时钟监控	90-99%	90-99%	时钟
电源监控	90-99%	90-99%	电源
安全状态机	90-99%	90-99%	控制逻辑

故障容错时间参考

系统类型	典型 FTTI	说明
刹车系统	10-50ms	安全关键
转向系统	50-100ms	安全关键
动力系统	100-200ms	重要
车身控制	100-500ms	一般
娱乐系统	>1s	非安全

---

故障诊断框架

症状1：SPFM 不满足要求

诊断步骤：

1. 计算 SPFM = 1 - Σ(单点故障率) / Σ(总故障率)
2. 识别贡献最大的单点故障
3. 检查安全机制覆盖率

判断标准：

SPFM 值	ASIL-A	ASIL-B	ASIL-C	ASIL-D
< 80%	不满足	不满足	不满足	不满足
80-90%	满足	不满足	不满足	不满足
90-97%	满足	满足	不满足	不满足
97-99%	满足	满足	满足	不满足
> 99%	满足	满足	满足	满足

根本原因定位：

根本原因	诊断特征	解决方案
安全机制不足	单点故障 FIT 高	增加安全机制
覆盖率低	诊断覆盖率 < 90%	改进诊断方法
高风险组件	特定组件 FIT 高	增加冗余或改进设计

症状2：LFM 不满足要求

诊断步骤：

1. 计算 LFM = 1 - Σ(潜伏故障率) / Σ(总故障率)
2. 识别潜伏故障来源
3. 检查周期性测试覆盖率

根本原因定位：

根本原因	诊断特征	解决方案
无周期性测试	潜伏故障多	增加自检程序
测试覆盖率低	潜伏故障 FIT 高	扩展测试范围
测试周期长	潜伏故障检测延迟	缩短测试间隔

症状3：PMHF 不满足要求

诊断步骤：

1. 计算 PMHF = 残余故障率 + 安全故障率 × 诊断周期
2. 识别高 FIT 组件
3. 评估残余风险

判断标准：

ASIL	PMHF 要求	说明
ASIL-A	< 1000 FIT	10^-6/h
ASIL-B	< 100 FIT	10^-7/h
ASIL-C	< 100 FIT	10^-7/h
ASIL-D	< 10 FIT	10^-8/h

---

故障注入方法

故障注入类型

类型	方法	适用场景	诊断覆盖率验证
硬件故障注入	激光、电磁、电压	硬件验证	高
软件故障注入	代码插入、断言	软件验证	中
仿真故障注入	RTL 注入	设计验证	高
形式化验证	形式化证明	设计验证	最高

RTL 故障注入示例

// 故障注入模块
module fault_injection #(
    parameter FAULT_TYPE = "STUCK_AT_0",  // STUCK_AT_0, STUCK_AT_1, BIT_FLIP
    parameter INJECT_PROBABILITY = 0.001   // 故障注入概率
)(
    input  wire clk,
    input  wire rst_n,
    input  wire [31:0] data_in,
    output reg  [31:0] data_out,
    input  wire inject_enable,    // 故障注入使能
    output reg  fault_detected    // 故障检测标志
);

    reg [31:0] fault_mask;
    real rand_val;

    always @(posedge clk or negedge rst_n) begin
        if (!rst_n) begin
            data_out <= 32'b0;
            fault_mask <= 32'b0;
            fault_detected <= 1'b0;
        end else begin
            if (inject_enable) begin
                // 生成随机故障掩码
                rand_val = $random / 2147483647.0;  // 归一化到 [0,1]
                if (rand_val < INJECT_PROBABILITY) begin
                    case (FAULT_TYPE)
                        "STUCK_AT_0": begin
                            fault_mask <= 32'hFFFFFFFF;
                            fault_detected <= 1'b1;
                        end
                        "STUCK_AT_1": begin
                            fault_mask <= 32'hFFFFFFFF;
                            fault_detected <= 1'b1;
                        end
                        "BIT_FLIP": begin
                            fault_mask <= $random;
                            fault_detected <= 1'b1;
                        end
                    endcase
                end else begin
                    fault_mask <= 32'b0;
                    fault_detected <= 1'b0;
                end
            end else begin
                fault_mask <= 32'b0;
                fault_detected <= 1'b0;
            end
            
            // 应用故障
            case (FAULT_TYPE)
                "STUCK_AT_0": data_out <= data_in & ~fault_mask;
                "STUCK_AT_1": data_out <= data_in | fault_mask;
                "BIT_FLIP":   data_out <= data_in ^ fault_mask;
                default:      data_out <= data_in;
            endcase
        end
    end

endmodule

故障注入测试计划

故障注入测试流程：
1. 定义故障模型
   - 单点故障：stuck-at-0, stuck-at-1, bit-flip
   - 潜伏故障：间歇故障、老化故障
   
2. 选择注入点
   - 关键信号：时钟、复位、使能
   - 数据通路：地址、数据、控制
   - 存储器：SRAM、寄存器
   
3. 注入故障
   - 仿真时间点：随机或特定
   - 注入持续时间：瞬时或永久
   - 注入位置：逐位或多位
   
4. 观察响应
   - 安全机制是否触发
   - 系统是否进入安全状态
   - 故障是否被检测
   
5. 计算覆盖率
   - 故障检测覆盖率 = 检测到的故障数 / 注入的故障数
   - 目标：覆盖率 ≥ 90%

---

步骤 1：确定 ASIL 等级

1.1 理解 ASIL 定义

ASIL (Automotive Safety Integrity Level) 是 ISO 26262 定义的功能安全等级。

ASIL 等级	安全要求	SPFM 最低	LFM 最低	典型应用
QM	无安全要求	-	-	娱乐系统
ASIL-A	基本	≥ 90%	≥ 60%	后视摄像头
ASIL-B	标准	≥ 90%	≥ 60%	仪表盘
ASIL-C	较高	≥ 97%	≥ 80%	转向辅助
ASIL-D	最高	≥ 99%	≥ 90%	刹车系统

1.2 进行危害分析和风险评估（HARA）

做什么： 识别潜在危害，确定 ASIL 等级。

步骤：

1. 列出所有潜在危害
2. 评估严重度（S1/S2/S3）
3. 评估暴露率（E1/E2/E3/E4）
4. 评估可控性（C1/C2/C3）
5. 查 ISO 26262 表格确定 ASIL

输出： 危害分析表

危害 ID	危害描述	严重度	暴露率	可控性	ASIL
H001	刹车信号丢失	S3	E4	C3	ASIL-D
H002	转向信号错误	S3	E3	C3	ASIL-C
H003	仪表盘显示错误	S2	E3	C2	ASIL-A

1.3 定义安全目标

做什么： 为每个危害定义安全目标。

危害 ID	安全目标	故障容错时间
H001	刹车信号必须正确	100ms
H002	转向信号必须正确	50ms

---

步骤 2：识别组件和失效模式

2.1 列出所有硬件模块

做什么： 列出设计中所有硬件模块。

模块 ID	模块名称	描述
M001	CPU	处理器内核
M002	SRAM	数据存储器
M003	Flash	程序存储器
M004	CAN 控制器	通信接口
M005	ADC	模数转换器

2.2 识别每个模块的失效模式

常见失效模式：

失效模式	描述
stuck-at-0	信号固定为 0
stuck-at-1	信号固定为 1
bit flip	比特翻转（瞬态）
数据损坏	数据错误
时序错误	建立保持失败
开路	连接断开
短路	连接短路

输出： 失效模式表

模块	失效模式	失效率 (FIT)
CPU	永久故障	100 FIT
CPU	瞬态故障	500 FIT
SRAM	单比特翻转	1000 FIT
SRAM	多比特翻转	10 FIT
Flash	数据损坏	50 FIT

---

步骤 2.5：FMEA 分析（失效模式与影响分析）

FMEA 是一种自下而上的分析方法，从组件失效模式开始分析其对系统的影响。

2.5.1 FMEA 分析流程

1. 列出所有组件
2. 识别每个组件的失效模式
3. 分析每个失效模式的局部影响
4. 分析每个失效模式的最终影响
5. 评估严重度、发生度、检测度
6. 计算风险优先级数（RPN）
7. 制定改进措施

2.5.2 FMEA 表格模板

项目	组件	失效模式	局部影响	最终影响	严重度(S)	发生度(O)	检测度(D)	RPN	改进措施
1	CPU	永久故障	计算错误	系统死机	10	2	3	60	双核锁步
2	SRAM	单比特翻转	数据错误	可能错误结果	7	5	2	70	ECC
3	Flash	数据损坏	程序错误	系统异常	9	2	4	72	CRC校验

2.5.3 FMEA 评分标准

严重度（S）评分：

分数	影响	描述
1-2	无影响	对系统无影响
3-4	轻微影响	对非安全功能有影响
5-6	中等影响	对性能有影响
7-8	严重影响	对安全功能有影响
9-10	危险影响	违反安全目标

发生度（O）评分：

分数	发生频率	描述
1-2	极低	< 1 次/年
3-4	低	1 次/年 - 1 次/月
5-6	中等	1 次/月 - 1 次/周
7-8	高	1 次/周 - 1 次/天
9-10	极高	> 1 次/天

检测度（D）评分：

分数	检测能力	描述
1-2	肯定检测	100% 检测
3-4	高概率检测	> 90% 检测
5-6	中等概率检测	50-90% 检测
7-8	低概率检测	10-50% 检测
9-10	几乎无法检测	< 10% 检测

2.5.4 RPN 分析

RPN 计算：

RPN = 严重度(S) × 发生度(O) × 检测度(D)
RPN 范围：1-1000

RPN 处理标准：

RPN 范围	风险等级	行动
1-100	低风险	可接受，无需改进
101-200	中风险	建议改进
201-500	高风险	必须改进
> 500	极高风险	立即改进或重新设计

---

步骤 2.6：FTA 分析（故障树分析）

FTA 是一种自上而下的分析方法，从顶事件开始分析可能的故障原因。

2.6.1 FTA 分析流程

1. 确定顶事件（不希望发生的事件）
2. 分析导致顶事件的直接原因
3. 使用逻辑门连接原因
4. 逐层分解，直到基本事件
5. 计算顶事件发生概率
6. 识别关键路径
7. 制定改进措施

2.6.2 FTA 逻辑门

逻辑门	符号	含义	计算公式
与门	AND	所有输入都发生才输出	P = P1 × P2 × ... × Pn
或门	OR	任一输入发生就输出	P = 1 - (1-P1) × (1-P2) × ...
非门	NOT	输入取反	P = 1 - P1
表决门	K/N	N 个输入中至少 K 个发生	组合计算

2.6.3 FTA 示例

顶事件： 刹车系统失效

                    刹车系统失效（顶事件）
                           │
                    ┌──────┴──────┐
                    │     OR      │
                    └──────┬──────┘
           ┌───────────────┼───────────────┐
           │               │               │
     ┌─────┴─────┐   ┌─────┴─────┐   ┌─────┴─────┐
     │ 控制器故障 │   │ 传感器故障 │   │ 执行器故障 │
     └─────┬─────┘   └─────┬─────┘   └─────┬─────┘
           │               │               │
     ┌─────┴─────┐         │         ┌─────┴─────┐
     │    OR    │         │         │    OR    │
     └─────┬─────┘         │         └─────┬─────┘
     ┌─────┼─────┐         │         ┌─────┼─────┐
     │     │     │         │         │     │     │
  CPU故障 电源故障    传感器断路    执行器断路 执行器短路

2.6.4 FTA 定量分析

基本事件概率：

基本事件	发生概率	FIT
CPU 故障	1e-6/h	1000
电源故障	1e-7/h	100
传感器断路	1e-7/h	100
执行器断路	1e-7/h	100
执行器短路	1e-7/h	100

计算顶事件概率：

P(控制器故障) = P(CPU故障) + P(电源故障) - P(CPU故障) × P(电源故障)
             = 1e-6 + 1e-7 - 1e-6 × 1e-7
             ≈ 1.1e-6/h

P(执行器故障) = P(执行器断路) + P(执行器短路) - P(执行器断路) × P(执行器短路)
             = 1e-7 + 1e-7 - 1e-7 × 1e-7
             ≈ 2e-7/h

P(刹车系统失效) = P(控制器故障) + P(传感器故障) + P(执行器故障)
                ≈ 1.1e-6 + 1e-7 + 2e-7
                ≈ 1.4e-6/h = 1400 FIT

2.6.5 最小割集分析

最小割集定义： 导致顶事件发生的最小基本事件集合。

计算方法：

1. 识别所有导致顶事件的路径
2. 找出最少的必要事件组合
3. 分析最小割集的重要性

最小割集示例：

最小割集	包含事件	概率	重要性
{CPU故障}	CPU故障	1e-6/h	最高
{电源故障}	电源故障	1e-7/h	中
{传感器断路}	传感器断路	1e-7/h	中
{执行器断路}	执行器断路	1e-7/h	中
{执行器短路}	执行器短路	1e-7/h	中

关键事件识别：

• CPU 故障概率最高，是最关键的改进点
• 应优先增加 CPU 的安全机制

2.6.6 FMEA 与 FTA 的配合使用

方法	方向	适用场景	优势
FMEA	自下而上	组件分析、制造问题	全面、系统
FTA	自上而下	安全分析、设计问题	聚焦、可视化
配合	双向分析	安全关键系统	互补验证

配合使用流程：

1. 使用 FTA 确定关键故障路径
2. 使用 FMEA 分析每个基本事件
3. 验证 FTA 的基本事件与 FMEA 的失效模式一致
4. 根据分析结果优化设计

---

步骤 3：分析失效影响

3.1 分析对安全目标的影响

做什么： 分析每个失效模式是否违反安全目标。

模块	失效模式	影响	是否违反安全目标
CPU	永久故障	系统死机	是（SG_1）
SRAM	单比特翻转	数据错误	可能（SG_2）
Flash	数据损坏	程序错误	是（SG_1）

3.2 影响分级

分级	描述
无影响	不影响功能，不影响安全
轻微影响	影响非安全功能
严重影响	影响安全功能
危险影响	违反安全目标

---

步骤 4：设计安全机制

4.1 选择安全机制

做什么： 为每个违反安全目标的失效模式分配安全机制。

模块	失效模式	安全机制	诊断覆盖率
CPU	永久故障	双核锁步 + 看门狗	99%
CPU	瞬态故障	ECC	99%
SRAM	单比特翻转	ECC (SECDED)	99%
SRAM	多比特翻转	双拷贝比较	90%
Flash	数据损坏	ECC + CRC	99%

4.2 安全机制详细设计

CPU 安全机制

安全机制	针对失效	诊断覆盖率	实现复杂度
双核锁步	永久/瞬态	99%	高
看门狗	永久	90%	低
内存保护	软件错误	60%	中
奇偶校验	瞬态	90%	低

存储器安全机制

安全机制	针对失效	诊断覆盖率	纠正能力
ECC (SECDED)	单比特错误	99%	可纠正
双拷贝	多比特错误	90%	可检测
CRC	数据完整性	99%	可检测
BIST	固定故障	90%	可检测

---

步骤 5：计算安全指标

5.1 计算 SPFM

公式：

SPFM = 1 - (单点故障失效率 / 总故障失效率)

计算示例：

失效模式	失效率 (FIT)	安全机制	DC	残留失效率
CPU 永久	100	锁步	99%	1
CPU 瞬态	500	ECC	99%	5
SRAM 单比特	1000	ECC	99%	10
总计	1600			16

SPFM = 1 - (16 / 1600) = 99%

5.2 计算 LFM

公式：

LFM = 1 - (潜伏故障失效率 / 总故障失效率)

5.3 检查是否满足 ASIL 要求

ASIL	SPFM 要求	LFM 要求	实际 SPFM	实际 LFM	是否满足
ASIL-D	≥ 99%	≥ 90%	99%	92%	满足

---

步骤 6：避免共因故障

6.1 识别共因故障来源

来源	风险
共用电源	电源故障同时影响冗余模块
共用时钟	时钟故障同时影响冗余模块
共用软件	软件 bug 同时影响冗余模块
环境因素	温度、辐射同时影响

6.2 避免措施

共因因素	避免措施
共用电源	独立电源域
共用时钟	独立时钟源
共用软件	多样化软件实现
温度	温度监控
辐射	屏蔽、ECC

---

步骤 7：功能安全验证

7.1 故障注入测试

做什么： 注入故障，验证安全机制是否正确检测和响应。

测试步骤：

1. 注入单点故障
2. 检查安全机制是否检测到
3. 检查是否进入安全状态
4. 统计诊断覆盖率

7.2 安全状态验证

检查清单：

• 故障检测后正确进入安全状态
• 安全状态输出值正确
• 安全状态持续时间满足要求
• 故障清除后正确恢复

7.3 安全指标验证

检查清单：

• SPFM 满足 ASIL 要求
• LFM 满足 ASIL 要求
• 所有安全机制都已验证
• 故障注入测试通过

---

步骤 8：输出功能安全文档

8.1 安全需求规格说明书

• 安全目标
• 功能安全需求
• 技术安全需求

8.2 FMEDA 分析报告

• 组件失效模式
• 安全机制
• SPFM/LFM 计算

8.3 安全验证报告

• 故障注入测试结果
• 安全指标达成情况

8.4 可追踪性矩阵

安全目标	安全需求	实现模块	验证测试	结论
SG_1	SR_1.1	CPU_Lockstep	test_001	PASS
SG_1	SR_1.2	Watchdog	test_002	PASS
SG_2	SR_2.1	SRAM_ECC	test_003	PASS

---

最终检查清单

功能安全完成前检查：

• ASIL 等级已确定
• HARA 分析已完成
• 所有组件失效模式已识别
• 安全机制已设计
• SPFM 满足 ASIL 要求
• LFM 满足 ASIL 要求
• 共因故障已避免
• 故障注入测试已通过
• 安全文档完整
• 可追踪性矩阵完整

---

反模式（要避免）

❌ 安全机制设计不足：SPFM/LFM 不满足 ASIL 要求

❌ 忽视共因故障：冗余系统同时失效

❌ 安全状态设计不当：故障后无法进入安全状态

❌ 测试不充分：没有故障注入测试

❌ 可追踪性不全：某个安全需求找不到实现或验证

❌ 安全机制被功能故障屏蔽：功能和安全机制同时失效

---

工具支持

工具	公司	用途
VC Functional Safety	Synopsys	功能安全分析
Medini Analyze	IKV	功能安全分析
Excel	-	FMEDA 表格

---

代理协作

• 使用 functional-safety-engineer 代理进行功能安全设计
• 每个安全需求必须可追踪到实现和验证
• 故障注入必须覆盖所有安全机制