Functional Safety Analysis

功能安全分析技能

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

When to Activate

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

行业经验数值

ASIL 等级要求

典型 FIT 值参考

安全机制诊断覆盖率

故障容错时间参考

故障诊断框架

症状1：SPFM 不满足要求

诊断步骤：

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

判断标准：

根本原因定位：

症状2：LFM 不满足要求

诊断步骤：

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

根本原因定位：

症状3：PMHF 不满足要求

诊断步骤：

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

判断标准：

故障注入方法

故障注入类型

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 定义的功能安全等级。

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

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

步骤：

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

输出： 危害分析表

1.3 定义安全目标

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

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

2.1 列出所有硬件模块

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

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

常见失效模式：

输出： 失效模式表

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

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

2.5.1 FMEA 分析流程

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

2.5.2 FMEA 表格模板

2.5.3 FMEA 评分标准

严重度（S）评分：

发生度（O）评分：

检测度（D）评分：

2.5.4 RPN 分析

RPN 计算：

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

RPN 处理标准：

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

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

2.6.1 FTA 分析流程

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

2.6.2 FTA 逻辑门

2.6.3 FTA 示例

顶事件： 刹车系统失效

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

2.6.4 FTA 定量分析

基本事件概率：

计算顶事件概率：

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 的安全机制

2.6.6 FMEA 与 FTA 的配合使用

配合使用流程：

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

步骤 3：分析失效影响

3.1 分析对安全目标的影响

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

3.2 影响分级

步骤 4：设计安全机制

4.1 选择安全机制

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

4.2 安全机制详细设计

CPU 安全机制

存储器安全机制

步骤 5：计算安全指标

5.1 计算 SPFM

公式：

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

计算示例：

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

5.2 计算 LFM

公式：

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

5.3 检查是否满足 ASIL 要求

步骤 6：避免共因故障

6.1 识别共因故障来源

6.2 避免措施

步骤 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 可追踪性矩阵

最终检查清单

功能安全完成前检查：

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

反模式（要避免）

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

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

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

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

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

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

工具支持

代理协作

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