# Functional Safety Analysis

> 功能安全分析技能 - FMEDA 分析、安全机制设计、ISO 26262 符合

- Skill: `tangyangchao578-art/functional-safety-analysis` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tangyangchao578-art/functional-safety-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tangyangchao578-art/functional-safety-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tangyangchao578-art (https://skillmd.com/u/tangyangchao578-art)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tangyangchao578-art/functional-safety-analysis

---


# 功能安全分析技能

当用户需要进行功能安全分析和安全机制设计时，启用此技能。符合 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 故障注入示例

```systemverilog
// 故障注入模块
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` 代理进行功能安全设计
- 每个安全需求必须可追踪到实现和验证
- 故障注入必须覆盖所有安全机制