ISO 26262-5 硬件级开发：构建安全的硬件基础

引言

在汽车电子系统中，硬件是功能安全的物理基础。无论软件多么完美，如果硬件设计存在缺陷，整个系统的安全性都会受到威胁。

想象一个真实场景：某汽车厂商的电动助力转向系统（EPS）采用了先进的控制算法，但由于选用的电机驱动芯片在高温环境下容易发生闩锁效应（latch-up），导致车辆在夏季高温天气中突然失去转向助力，造成了多起事故。

这个案例告诉我们：**硬件级开发不仅要满足性能要求，更要确保在所有预期的工作条件下都能安全运行。**这正是 ISO 26262-5 硬件级开发的核心使命。

硬件级开发的目标和范围

硬件级开发的核心活动

ISO 26262-5 定义了硬件级开发的七个核心活动：

1. 硬件安全需求（HSR）的初始化

   • 分析系统级安全需求
   • 硬件架构的初步设计
   • 硬件安全需求清单

2. 硬件架构设计

   • 设计硬件组件的架构
   • 定义硬件组件之间的接口
   • 评估硬件架构的适用性

3. 硬件详细设计

   • 电路设计
   • 元器件选型
   • PCB 布局布线

4. 硬件架构指标评估

   • 单点故障度量（SPFM）
   • 潜在故障度量（LFM）
   • 硬件架构度量（HF）

5. FMEDA 分析

   • 识别硬件失效模式
   • 评估失效影响
   • 计算硬件架构指标

6. 硬件集成和验证

   • 硬件原型制作
   • 硬件测试
   • 硬件验证

7. 硬件生产

   • 生产过程开发
   • 生产质量控制

硬件级开发的输入和输出

输入

• 系统安全需求（SSyR）：来自系统级开发
• 技术安全概念（TSC）：来自系统级开发
• 硬件/软件接口规范（HSIS）：来自系统级开发
• 硬件约束：成本、尺寸、功耗、温度范围等

输出

• 硬件安全需求（HSR）：硬件级安全需求
• 硬件架构设计文档：硬件架构设计
• 硬件详细设计文档：电路设计、元器件清单
• FMEDA 报告：失效模式、影响和诊断分析
• 硬件测试报告：测试结果
• 硬件生产文档：生产流程、质量控制

硬件安全需求（HSR）的初始化

HSR 的来源

硬件安全需求主要来自以下几个方面：

1. 从系统级安全需求（SSyR）派生
2. 从技术安全概念（TSC）派生
3. 从硬件/软件接口规范（HSIS）派生

HSR 的分类

1. 功能性需求

描述硬件应该实现的功能。

2. 性能需求

描述硬件的性能指标，如响应时间、精度等。

3. 安全机制需求

描述硬件应该实现的安全机制，如看门狗、ECC 内存等。

4. 环境需求

描述硬件应该满足的环境条件，如温度、湿度、振动等。

5. 可靠性需求

描述硬件的可靠性要求，如 FIT 率、MTBF 等。

案例：制动系统的硬件安全需求

来自 SSyR 的 HSR：

HSR-1.1（来自 SSyR-1.1）：

“压力传感器的采样周期不得大于 10 ms”

具体要求：

• 采样频率 ≥ 100 Hz
• ADC 转换时间 ≤ 5 ms
• 数据传输时间 ≤ 2 ms

HSR-1.2（来自 SSyR-1.3）：

“系统应实现压力传感器故障诊断算法”

具体要求：

• 硬件应支持开路检测
• 硬件应支持短路检测
• 硬件应支持信号范围检测

HSR-1.3（来自 SSyR-1.3.1）：

“硬件应实现独立于 CPU 的看门狗定时器”

具体要求：

• 看门狗类型：外部窗口看门狗
• 超时时间：可配置（默认 100 ms）
• 复位类型：系统复位
• 独立性：看门狗的时钟和电源应独立于 CPU

硬件架构设计

硬件架构设计的原则

1. 独立性原则：冗余硬件组件之间应该独立，避免共因故障
2. 多样性原则：不同冗余通道采用不同的实现方式
3. 诊断性原则：硬件应具备自诊断能力
4. 容错性原则：硬件应能容忍一定的故障

硬件架构的类型

1. 单通道架构

适用于 ASIL A/B。

优点：

• 成本低
• 功耗低
• 空间小

缺点：

• 安全性有限
• 单点故障可能导致危险失效

2. 双通道冗余架构

适用于 ASIL C/D。

优点：

• 安全性高
• 可以容忍一个通道的故障

缺点：

• 成本中等
• 功耗中等
• 空间中等

3. 三模冗余架构（TMR）

适用于 ASIL D 高要求场景。

优点：

• 安全性最高
• 可以容忍一个通道的故障

缺点：

• 成本高
• 功耗高
• 空间大

案例：ASIL D 系统的三模冗余架构

对于 ASIL D 的电子驻车制动系统（EPB），采用三模冗余架构：

           传感器
             │
    ┌────────┼────────┐
    │        │        │
  MCU1     MCU2     MCU3
    │        │        │
    └────────┼────────┘
             │
         投票器
             │
          执行器

可靠性计算：

假设单个 MCU 的可靠度为 $R = 0.9999$（在任务时间内）。

系统成功运行的条件是：至少两个 MCU 正常工作。

$$ R_{\text{system}} = R^3 + 3 \times R^2 \times (1-R) $$

代入数值： $$ R_{\text{system}} = 0.9999^3 + 3 \times 0.9999^2 \times 0.0001 $$ $$ R_{\text{system}} = 0.9997 + 0.00029997 $$ $$ R_{\text{system}} = 0.99999997 $$

可以看到，通过三模冗余，系统可靠度从 99.99% 提升到了 99.999997%。

硬件详细设计

电路设计

电路设计包括原理图设计和 PCB 布局布线。

原理图设计

原理图设计要点：

1. 元器件选型：选择符合功能安全要求的元器件
2. 电路保护：添加过压、过流、防静电保护
3. 滤波和去耦：添加滤波电容、去耦电容
4. 信号完整性：考虑信号的阻抗匹配、串扰、反射等问题

PCB 布局布线

PCB 布局布线要点：

1. 元器件布局：考虑散热、EMC、信号完整性
2. 走线设计：考虑阻抗匹配、差分走线、地平面
3. 电源设计：考虑电源分配、去耦、纹波
4. EMC 设计：考虑屏蔽、滤波、地平面

元器件选型

元器件选型的原则

1. 质量等级：选择汽车级或工业级元器件
2. 可靠性：选择低 FIT 率的元器件
3. 功能安全认证：选择有功能安全认证的元器件
4. 可获取性：选择长期可获取的元器件
5. 成本：在满足要求的前提下，选择成本合理的元器件

元器件的可靠性指标

FIT 率（Failure In Time）：每十亿小时内的故障次数。

$$ \text{FIT} = \frac{10^9}{\text{MTBF}} $$

其中，MTBF（Mean Time Between Failures）是平均故障间隔时间。

案例：MCU 选型

对于 ASIL D 的应用，MCU 选型要求：

案例：制动系统的硬件详细设计

原理图设计

MCU 电路：

        3.3V
         │
         │
    ┌────▼────┐
    │  MCU1   │
    │  ┌───┐  │
    │  │CPU│  │
    │  └───┘  │
    │  ┌───┐  │
    │  │RAM│  │
    │  │ECC│  │
    │  └───┘  │
    └────┬────┘
         │
        GND

传感器电路：

    5V
     │
     │
    ┌▼────────────────────────────┐
    │   压力传感器                │
    │   ┌──────────────────────┐  │
    │   │  信号调理电路        │  │
    │   └──────────────────────┘  │
    └────────────┬────────────────┘
                 │
                 │ 0-5V 模拟信号
                 │
            ┌────▼────┐
            │  ADC    │
            └────┬────┘
                 │
                 │ 12-bit 数字信号
                 │
             ┌───▼───┐
             │ MCU1  │
             └───────┘

看门狗电路：

    3.3V
     │
     │
  ┌──▼──┐
  │WDT  │
  │Timer│
  └──┬──┘
     │
     │ 复位信号
     │
  ┌──▼──┐
  │MCU1 │
  └──┬──┘
     │
     │ 喂狗信号
     │
  ┌──▼──┐
  │WDT  │
  │Timer│
  └──┬──┘
     │
    GND

PCB 布局布线

分层设计：

┌────────────────────────────────┐
│ 第1层：信号层（Top Layer）       │
│ - MCU                            │
│ - 传感器                         │
│ - 看门狗                         │
├────────────────────────────────┤
│ 第2层：地层（Ground Plane）      │
│ - 完整地平面                     │
├────────────────────────────────┤
│ 第3层：电源层（Power Plane）     │
│ - 5V 电源平面                   │
│ - 3.3V 电源平面                 │
├────────────────────────────────┤
│ 第4层：信号层（Bottom Layer）     │
│ - 去耦电容                       │
│ - 测试点                         │
└────────────────────────────────┘

去耦电容布局：

    5V
     │
     │
  ┌──▼──┐
  │ 10uF│
  │ 电容│
  └──┬──┘
     │
     │
  ┌──▼──┐
  │ 0.1uF│
  │ 电容│
  └──┬──┘
     │
     │
  ┌──▼──┐
  │ MCU1 │
  └──┬──┘
     │
    GND

硬件架构指标

评估

ISO 26262-5 定义了三个硬件架构指标：

1. 单点故障度量（SPFM）

SPFM（Single Point Fault Metric） 衡量的是系统对单点故障的防护能力。

$$ \text{SPFM} = \frac{\sum \lambda_{\text{SPF}} - \sum \lambda_{\text{RF}}}{\sum \lambda_{\text{SPF}}} \times 100% $$

其中：

• $\lambda_{\text{SPF}}$：单点故障率
• $\lambda_{\text{RF}}$：未被安全机制覆盖的单点故障率

ASIL 要求：

2. 潜在故障度量（LFM）

LFM（Latent Fault Metric） 衡量的是系统对潜在故障的检测能力。

$$ \text{LFM} = \frac{\sum \lambda_{\text{LF}} - \sum \lambda_{\text{RF}}}{\sum \lambda_{\text{LF}}} \times 100% $$

其中：

• $\lambda_{\text{LF}}$：潜在故障率
• $\lambda_{\text{RF}}$：未被安全机制覆盖的潜在故障率

ASIL 要求：

3. 硬件架构度量（HF）

HF（Hardware Architecture Metric） 结合了 SPFM 和 LFM，用于评估硬件架构的适用性。

ASIL 要求：

案例：制动系统的硬件架构指标计算

假设制动系统的硬件组件包括：

SPFM 计算：

$$ \sum \lambda_{\text{SPF}} = 40 + 40 + 15 + 15 + 25 = 135 \text{ FIT} $$

$$ \sum \lambda_{\text{RF}} = 40 \times (1 - 0.9) + 40 \times (1 - 0.9) + 15 \times (1 - 0.8) + 15 \times (1 - 0.8) + 25 \times (1 - 0.7) $$ $$ \sum \lambda_{\text{RF}} = 4 + 4 + 3 + 3 + 7.5 = 21.5 \text{ FIT} $$

$$ \text{SPFM} = \frac{135 - 21.5}{135} \times 100% = 84.07% $$

LFM 计算：

$$ \sum \lambda_{\text{LF}} = 10 + 10 + 5 + 5 + 5 = 35 \text{ FIT} $$

$$ \sum \lambda_{\text{RF}} = 10 \times (1 - 0.9) + 10 \times (1 - 0.9) + 5 \times (1 - 0.8) + 5 \times (1 - 0.8) + 5 \times (1 - 0.7) $$ $$ \sum \lambda_{\text{RF}} = 1 + 1 + 1 + 1 + 1.5 = 5.5 \text{ FIT} $$

$$ \text{LFM} = \frac{35 - 5.5}{35} \times 100% = 84.29% $$

结论：

• SPFM = 84.07%，满足 ASIL B 要求（≥ 90%），但不满足 ASIL C/D 要求
• LFM = 84.29%，满足 ASIL C 要求（≥ 80%），但不满足 ASIL D 要求

如果该系统的 ASIL 等级是 C，则满足要求。如果是 ASIL D，则需要改进安全机制，提高覆盖率。

FMEDA 分析

FMEDA 的定义

FMEDA（Failure Modes, Effects and Diagnostic Analysis） 是一种用于分析硬件失效模式、影响和诊断能力的方法。

FMEDA 的步骤

第一步：识别硬件组件

列出系统中的所有硬件组件。

第二步：识别失效模式

对于每个硬件组件，识别其可能的失效模式。

第三步：分析失效影响

分析每个失效模式对系统的影响。

第四步：分析诊断覆盖率

分析现有安全机制对失效模式的诊断覆盖率。

第五步：计算硬件架构指标

计算 SPFM 和 LFM。

FMEDA 表格示例

案例：制动系统的 FMEDA 分析

第一步：识别硬件组件

制动系统的硬件组件：

• MCU1（主控制器）
• MCU2（备份控制器）
• 压力传感器1
• 压力传感器2
• 阀门驱动器
• 看门狗定时器
• 电源管理芯片

第二步：识别失效模式

以 MCU1 为例：

总计：60 FIT

第三步：分析失效影响

第四步：分析诊断覆盖率

第五步：计算硬件架构指标

单点故障（SPF）：

• CPU 挂死：10 FIT
• Flash 坏块：15 FIT
• 时钟故障：5 FIT
• I/O 故障：10 FIT

潜在故障（LF）：

• RAM 位翻转：20 FIT

SPFM 计算：

$$ \sum \lambda_{\text{SPF}} = 10 + 15 + 5 + 10 = 40 \text{ FIT} $$

$$ \sum \lambda_{\text{RF}} = 10 \times (1 - 0.9) + 15 \times (1 - 0.95) + 5 \times (1 - 0.7) + 10 \times (1 - 0.85) $$ $$ \sum \lambda_{\text{RF}} = 1 + 0.75 + 1.5 + 1.5 = 4.75 \text{ FIT} $$

$$ \text{SPFM} = \frac{40 - 4.75}{40} \times 100% = 88.125% $$

LFM 计算：

$$ \sum \lambda_{\text{LF}} = 20 \text{ FIT} $$

$$ \sum \lambda_{\text{RF}} = 20 \times (1 - 0.8) = 4 \text{ FIT} $$

$$ \text{LFM} = \frac{20 - 4}{20} \times 100% = 80% $$

结论：

• SPFM = 88.125%，满足 ASIL B 要求（≥ 90%），但不满足 ASIL C/D 要求
• LFM = 80%，满足 ASIL C 要求（≥ 80%），但不满足 ASIL D 要求

如果该系统的 ASIL 等级是 C，则满足要求。如果是 ASIL D，则需要改进安全机制，特别是提高时钟故障和 I/O 故障的诊断覆盖率。

硬件集成和验证

硬件集成

硬件集成的步骤：

1. 原型制作：制作硬件原型板
2. 硬件测试：测试硬件的基本功能
3. 硬件验证：验证硬件满足设计要求
4. 硬件确认：确认硬件满足安全需求

硬件测试

测试类型

1. 功能测试：

   • 测试硬件的基本功能
   • 测试硬件的性能指标

2. 环境测试：

   • 温度测试（高温、低温、温度循环）
   • 湿度测试
   • 振动测试
   • EMC 测试

3. 可靠性测试：

   • 寿命测试
   • 加速寿命测试

4. 安全测试：

   • 故障注入测试
   • 安全机制测试

案例：制动系统的硬件测试

测试用例 1：MCU 看门狗测试

测试目的：验证看门狗定时器能够检测到 CPU 挂死。

测试步骤：

1. 系统上电初始化
2. 正常运行，喂狗
3. 模拟 CPU 挂死（停止喂狗）
4. 等待看门狗超时
5. 检查系统是否复位

预期结果：

• 看门狗超时时间到后，系统复位

测试用例 2：压力传感器开路测试

测试目的：验证压力传感器开路检测功能。

测试步骤：

1. 系统上电初始化
2. 正常运行，读取压力传感器数据
3. 断开压力传感器1（模拟开路故障）
4. 等待诊断周期
5. 检查系统是否检测到开路故障

预期结果：

• 系统在诊断周期内检测到压力传感器1开路故障
• 系统切换到压力传感器2
• 系统向驾驶员发出报警

测试用例 3：RAM 位翻转测试

测试目的：验证 ECC 能够检测和纠正 RAM 位翻转。

测试步骤：

1. 系统上电初始化
2. 向 RAM 写入已知数据
3. 使用硬件故障注入工具注入位翻转
4. 读取 RAM 数据
5. 检查 ECC 是否检测到位翻转并纠正

预期结果：

• ECC 检测到位翻转
• ECC 纠正位翻转
• 系统记录错误

实战案例：电动车电池管理系统（BMS）的硬件级开发

让我们以一个实际项目为例，展示硬件级开发的完整流程。

项目背景

某电动车厂商正在开发新一代 BMS，用于管理 400V/80kWh 的动力电池包。ASIL 等级：C。

第一步：硬件安全需求初始化

来自系统级开发的 HSR：

HSR-1.1：

“BMS 应每 10 ms 读取一次所有单体电池电压”

具体要求：

• 电压采样频率 ≥ 100 Hz
• 采样精度 ≥ 5 mV
• 采样通道数 ≥ 96（假设 96 个单体电池）

HSR-1.2：

“BMS 应实现过温保护，当电池温度超过 60°C 时切断充电”

具体要求：

• 温度采样频率 ≥ 10 Hz
• 温度精度 ≥ 1°C
• 温度检测点数 ≥ 32（假设 32 个温度传感器）

HSR-1.3：

“BMS 应实现过充保护，当电池电压超过 4.2V 时切断充电”

具体要求：

• 电压采样实时性：采样 + 判断 ≤ 20 ms
• 切断充电时间：≤ 50 ms

第二步：硬件架构设计

双通道冗余架构：

                    电池模组
                      │
          ┌───────────┼───────────┐
          │           │           │
       模组1       模组2        模组N
          │           │           │
    ┌─────┼─────┐ ┌───┼─────┐ ┌──┼─────┐
    │单体电池单体│ │单体电池单体│ │单体电池单体│
    │电压监测   │ │电压监测   │ │电压监测   │
    │温度监测   │ │温度监测   │ │温度监测   │
    └─────┬─────┘ └───┬─────┘ └──┬─────┘
          │           │           │
          └───────────┼───────────┘
                      │
                ┌─────┴─────┐
                │  模组控制器│
                │  （MCU）   │
                └─────┬─────┘
                      │
                ┌─────┴─────┐
                │ 主控制器  │
                │  （MCU）  │
                └─────┬─────┘
                      │
                ┌─────┴─────┐
                │ 安全监控器│
                └──────────┘

第三步：硬件详细设计

模组控制器电路：

• MCU：Infineon XMC4200（ASIL B 认证）
• ADC：TI ADS1118（16-bit，4 通道）
• 温度传感器：NTC 10kΩ（β = 3950）
• 通信：隔离 CAN（ISO 1050）

主控制器电路：

• MCU：Infineon AURIX TC377（ASIL D 认证）
• 看门狗：Maxim MAX6370（窗口看门狗）
• 通信：双 CAN（CAN 1 + CAN 2）
• 电源：隔离 DC/DC 转换器

第四步：FMEDA 分析

MCU 失效模式分析：

ADC 失效模式分析：

SPFM 计算：

$$ \sum \lambda_{\text{SPF}} = 10 + 5 = 15 \text{ FIT} $$

$$ \sum \lambda_{\text{RF}} = 10 \times (1 - 0.95) + 5 \times (1 - 0.9) = 0.5 + 0.5 = 1 \text{ FIT} $$

$$ \text{SPFM} = \frac{15 - 1}{15} \times 100% = 93.33% $$

LFM 计算：

$$ \sum \lambda_{\text{LF}} = 15 + 20 + 3 = 38 \text{ FIT} $$

$$ \sum \lambda_{\text{RF}} = 15 \times (1 - 0.9) + 20 \times (1 - 0.85) + 3 \times (1 - 0.7) $$ $$ \sum \lambda_{\text{RF}} = 1.5 + 3 + 0.9 = 5.4 \text{ FIT} $$

$$ \text{LFM} = \frac{38 - 5.4}{38} \times 100% = 85.79% $$

结论：

• SPFM = 93.33%，满足 ASIL C 要求（≥ 97%？不对，看下表）
• 等等，让我重新检查 ASIL 要求

所以 SPFM = 93.33% 满足 ASIL B 要求，但不满足 ASIL C 要求（≥ 97%）。 LFM = 85.79% 满足 ASIL C 要求（≥ 80%）。

如果系统的 ASIL 等级是 C，则 SPFM 不满足要求，需要改进安全机制，提高覆盖率。

第五步：硬件测试

测试用例 1：电压采样精度测试

测试目的：验证电压采样精度 ≥ 5 mV。

测试步骤：

1. 使用标准电压源施加已知电压
2. 读取 BMS 采样值
3. 计算误差
4. 重复测试多个电压点

预期结果：

• 所有采样点的误差 ≤ 5 mV

测试用例 2：过温保护测试

测试目的：验证过温保护功能。

测试步骤：

1. 系统上电初始化
2. 模拟温度升高（使用温度箱）
3. 当温度超过 60°C 时，检查系统是否切断充电
4. 检查切断时间 ≤ 50 ms

预期结果：

• 温度 > 60°C 时，系统切断充电
• 切断时间 ≤ 50 ms

常见错误和最佳实践

常见错误

1. 硬件架构设计不合理

   • 冗余设计不足
   • 缺乏独立性
   • 共因故障未考虑

2. 元器件选型不当

   • 选用了非汽车级元器件
   • 忽视了功能安全认证
   • 可靠性数据不准确

3. FMEDA 分析不完整

   • 未识别所有失效模式
   • 安全机制覆盖率过高估计
   • 硬件架构指标计算错误

4. 硬件测试不充分

   • 只测试正常场景
   • 未进行故障注入测试
   • 环境测试不全面

最佳实践

1. 使用专业的 FMEDA 工具

   • 如 Reliasoft FMEDA、Isograph Reliability Workbench
   • 提高分析效率和准确性

2. 参考元器件厂商的 FMEDA 报告

   • MCU、传感器等厂商通常提供 FMEDA 报告
   • 可以作为分析的参考

3. 充分的硬件测试

   • 覆盖所有失效模式
   • 使用硬件故障注入工具
   • 进行全面的可靠性测试

4. 建立失效案例库

   • 记录实际发生的故障
   • 定期回顾和更新 FMEDA

总结

ISO 26262-5 硬件级开发是构建安全的硬件基础的关键环节。通过本文的深入解读和丰富的案例实践，我们掌握了：

1. 硬件安全需求（HSR）的初始化：

   • HSR 的来源和分类
   • HSR 的制定方法

2. 硬件架构设计：

   • 硬件架构设计的原则
   • 单通道、双通道、三模冗余架构
   • 三模冗余的可靠性计算

3. 硬件详细设计：

   • 电路设计（原理图设计、PCB 布局布线）
   • 元器件选型
   • 制动系统的硬件设计实例

4. 硬件架构指标评估：

   • SPFM（单点故障度量）的计算
   • LFM（潜在故障度量）的计算
   • HF（硬件架构度量）
   • ASIL 要求对照

5. FMEDA 分析：

   • FMEDA 的五个步骤
   • FMEDA 表格的制作
   • 制动系统的 FMEDA 实践

6. 硬件集成和验证：

   • 硬件集成的步骤
   • 硬件测试的类型
   • 制动系统的测试用例

7. 实战案例：

   • BMS 硬件级开发完整实践

核心要点：

• 硬件是功能安全的物理基础，必须确保安全可靠
• 硬件架构设计必须考虑独立性、多样性和诊断性
• FMEDA 是评估硬件安全性的重要方法，必须认真执行
• 硬件架构指标（SPFM、LFM）必须满足 ASIL 要求
• 充分的硬件测试是确保硬件安全的关键

在下一篇文章中，我们将深入解读 ISO 26262-6 软件级开发部分，学习如何设计和开发安全的软件。

延伸阅读

• ISO 26262-1: 词汇
• ISO 26262-2: 功能安全管理
• ISO 26262-4: 系统级开发
• ISO 26262-6: 软件级开发
• ISO 26262 整体综述