ISO 26262-10 指南：标准实施的实践指南

引言

ISO 26262 标准提供了完整的汽车功能安全要求，但在实际应用中，如何正确理解和应用这些要求是一个挑战。ISO 26262-10 指南部分正是为了解决这个问题而设计的，它提供了详细的解释、示例和最佳实践。

想象一个真实场景：某汽车电子公司的工程师在实施 ASIL D 项目时，对于如何确定硬件架构指标（SPFM、LFM）存在困惑。不同的工程师有不同的理解，导致项目进展缓慢。

这个案例告诉我们：**需要详细的指南和示例来帮助正确理解和应用 ISO 26262 标准。**这正是 ISO 26262-10 指南部分的核心使命。

指南的结构和内容

指南的目的

ISO 26262-10 的主要目的是：

1. 解释标准要求：详细解释 ISO 26262 各部分的要求
2. 提供示例：提供实际应用的示例
3. 分享最佳实践：分享行业最佳实践
4. 解决常见问题：解决常见的问题和困惑

指南的内容

ISO 26262-10 包含以下内容：

1. 概念阶段的指南

   • 危害分析（HARA）的示例
   • ASIL 确定的示例
   • 功能安全概念的示例

2. 系统级开发的指南

   • 系统架构设计的示例
   • 技术 安全概念的示例
   • 系统集成和测试的示例

3. 硬件级开发的指南

   • 硬件架构设计的示例
   • FMEDA 分析的示例
   • 硬件架构指标计算的示例

4. 软件级开发的指南

   • 软件架构设计的示例
   • 软件单元测试的示例
   • 软件集成和测试的示例

5. 生产和运行的指南

   • 生产一致性的示例
   • 服务和维护的示例

6. 支持过程的指南

   • 配置管理的示例
   • 文档管理的示例
   • 工具置信度评估的示例

7. ASIL 导向分析的指南

   • FMEA 的示例
   • FTA 的示例
   • STPA 的示例

概念阶段的指南

危害分析（HARA）的示例

示例 1：制动系统的 HARA

系统功能：电子液压制动系统（EHB）

潜在危害：

安全目标：

SG-1：

“制动助力系统的故障不得导致制动性能的显著降低，ASIL C”

SG-2：

“制动系统不得在任何非驾驶员意图的情况下施加制动力，ASIL D”

示例 2：转向系统的 HARA

系统功能：电动助力转向系统（EPS）

潜在危害：

安全目标：

SG-1：

“转向助力系统的故障不得导致转向力的突然完全丧失，ASIL B”

SG-2：

“EPS 系统不得导致转向反向，ASIL D”

ASIL 确定的示例

示例 1：ASIL C 的确定

危害：制动助力完全失效

严重性（S）：

• 刹车距离显著增加
• 可能导致碰撞事故
• 生存概率高
• 结论：S3（危及生命的伤害，生存概率 > 50%）

暴露率（E）：

• 每次驾驶都会使用制动系统
• 助力失效可能发生在任何时刻
• 结论：E4（高概率）

可控性（C）：

• 驾驶员会察觉到踏板变硬
• 需要用更大的力量踩刹车
• 对于未经过训练的驾驶员，紧急情况下可能反应不足
• 结论：C2（正常可控到难于控制之间）

ASIL 确定： $$ \text{ASIL} = f(S3, E4, C2) = \text{ASIL C} $$

示例 2：ASIL D 的确定

危害：制动误动作

严重性（S）：

• 后车追尾可能导致严重伤害
• 车辆失控可能引发连环事故
• 生存概率不确定
• 结论：S3（危及生命的伤害，生存概率 < 50%）

暴露率（E）：

• 虽然是偶发性故障，但一旦发生影响重大
• 考虑到软件 bug 或传感器错误可能导致误动作
• 结论：E3（中等概率）

可控性（C）：

• 驾驶员可能无法及时识别误制动
• 后车可能反应不及
• 结论：C3（难于控制）

ASIL 确定： $$ \text{ASIL} = f(S3, E3, C3) = \text{ASIL D} $$

功能安全概念的示例

示例：制动系统的功能安全概念

安全目标（SG-1）：

“制动助力系统的故障不得导致制动性能的显著降低，ASIL C”

技术实现策略：

1. 冗余架构：双通道控制器架构
2. 故障检测：压力传感器冗余、电流监测、看门狗
3. 故障容错：主通道故障时切换到备份通道
4. 故障恢复：系统重启、故障记录

容错时间间隔（FTTI）计算：

$$ \text{FTTI} = \text{故障检测时间} + \text{故障处理时间} + \text{安全状态转换时间} $$ $$ \text{FTTI} = 15 + 10 + 100 = 125 \text{ ms} $$

功能安全需求（FSR）：

FSR-1.1：

“系统应在 100 ms 内检测到制动助力失效”

FSR-1.2：

“在检测到助力失效后，系统应立即启动机械制动备份”

FSR-1.3：

“系统应向驾驶员提供视觉和听觉报警”

系统级开发的指南

系统架构设计的示例

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

系统：电子驻车制动系统（EPB），ASIL D

架构设计：

           传感器
             │
    ┌────────┼────────┐
    │        │        │
  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.99999997 $$

结论：

• 单个 MCU 的可靠度为 99.99%
• 通过三模冗余，系统可靠度提升到 99.999997%

技术安全概念的示例

示例：制动系统的技术安全概念

硬件架构：

                    电源管理单元
                         │
          ┌──────────────┼──────────────┐
          │              │              │
    主控制器（MCU1）  备份控制器（MCU2）  安全监控器
          │              │              │
          │              │              │
    压力传感器1      压力传感器2      阀门驱动
          │              │              │
          └──────────────┼──────────────┘
                         │
                    液压执行单元
                         │
                    车轮制动器

软件架构：

应用层
    ├── 控制算法层
    │   ├── 制动控制
    │   ├── 压力调节
    │   └── 车辆稳定性控制
    │
    ├── 故障诊断模块
    │   ├── 传感器故障诊断
    │   ├── 执行器故障诊断
    │   └── 系统故障诊断
    │
    ├── 安全管理模块
    │   ├── 故障处理逻辑
    │   ├── 安全状态管理
    │   └── 故障记录
    │
    └── 通信模块
        ├── CAN 通信
        └── 诊断服务

系统集成和测试的示例

示例：制动系统的系统集成测试

测试用例：

硬件级开发的指南

硬件架构设计的示例

示例：ASIL C 系统的双通道冗余架构

系统：电动助力转向系统（EPS），ASIL C

架构设计：

                    电池
                     │
          ┌──────────┼──────────┐
          │          │          │
      主通道      备份通道    安全监控器
          │          │          │
          │          │          │
      主MCU      备份MCU      看门狗
          │          │          │
          └──────────┼──────────┘
                     │
                  转向电机

可靠性计算：

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

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

$$ R_{\text{system}} = 1 - (1 - R)^2 $$ $$ R_{\text{system}} = 1 - 0.001^2 = 0.999999 $$

结论：

• 单个 MCU 的可靠度为 99.9%
• 通过双通道冗余，系统可靠度提升到 99.9999%

FMEDA 分析的示例

示例：MCU 的 FMEDA 分析

组件：MCU

失效模式分析：

SPFM 计算：

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

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

$$ \text{SPFM} = \frac{25 - 4}{25} \times 100% = 84% $$

LFM 计算：

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

$$ \sum \lambda_{\text{RF}} = 15 \times (1 - 0.9) + 20 \times (1 - 0.8) $$ $$ \sum \lambda_{\text{RF}} = 1.5 + 4 = 5.5 \text{ FIT} $$

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

结论：

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

如果系统的 ASIL 等级是 C，则需要改进安全机制，提高 SPFM。

硬件架构指标计算的示例

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

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

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，则 SPFM 不满足要求，需要改进安全机制。

软件级开发的指南

软件架构设计的示例

示例：分层架构

系统：制动控制系统

架构设计：

应用层（Application Layer）
    ├── 制动控制模块
    │   ├── 压力控制算法
    │   ├── 车轮速度控制
    │   └── 车辆稳定性控制
    │
    ├── 故障诊断模块
    │   ├── 传感器故障诊断
    │   ├── 执行器故障诊断
    │   └── 系统故障诊断
    │
    ├── 安全管理模块
    │   ├── 故障处理逻辑
    │   ├── 安全状态管理
    │   └── 故障记录
    │
    └── 通信模块
        ├── CAN 通信
        └── 诊断服务
    │
中间件层（Middleware Layer）
    ├── 操作系统抽象层（OSAL）
    ├── 通信层（Communication Layer）
    └── 存储层（Storage Layer）
    │
硬件抽象层（HAL）
    ├── ADC 驱动
    ├── GPIO 驱动
    ├── PWM 驱动
    ├── 定时器驱动
    └── 看门狗驱动
    │
硬件层（Hardware Layer）
    ├── MCU
    ├── 传感器
    ├── 执行器
    └── 电源管理

软件单元测试的示例

示例：制动控制函数的单元测试

测试用例设计：

#include <unity.h>
#include "BrakingControl.h"

void setUp(void)
{
    // 初始化
    BrakingControl_Init();
}

void tearDown(void)
{
    // 清理
}

// 测试用例 1：正常输入
void test_BrakingControl_NormalInput(void)
{
    BrakingControlInput input = {0};
    BrakingControlOutput output = {0};

    input.pedal_position = 0.5f;

    BrakingControl_Run(&input, &output);

    TEST_ASSERT_EQUAL_FLOAT(50.0f, output.target_pressure);
}

// 测试用例 2：踏板位置超出上限
void test_BrakingControl_PedalPositionExceedsMaximum(void)
{
    BrakingControlInput input = {0};
    BrakingControlOutput output = {0};

    input.pedal_position = 1.5f;

    BrakingControl_Run(&input, &output);

    TEST_ASSERT_EQUAL_FLOAT(100.0f, output.target_pressure);
}

// 测试用例 3：踏板位置超出下限
void test_BrakingControl_PedalPositionExceedsMinimum(void)
{
    BrakingControlInput input = {0};
    BrakingControlOutput output = {0};

    input.pedal_position = -0.5f;

    BrakingControl_Run(&input, &output);

    TEST_ASSERT_EQUAL_FLOAT(0.0f, output.target_pressure);
}

生产和运行的指南

生产一致性的示例

示例：制动系统的生产一致性

关键特性识别：

过程控制：

产品验证：

支持过程的指南

配置管理的示例

示例：配置项标识

标识格式：

[项目代码]-[文档类型]-[版本号]-[修订号]

示例：

文档管理的示例

示例：文档清单

工具置信度评估的示例

示例：编译器的工具置信度评估

工具：GNU Compiler Collection (GCC)

步骤 1：工具分类

• GCC 用于编译安全相关代码
• 可能影响安全相关的工作产品
• 类别：TCL 3

步骤 2：置信度评估

TCL 计算：

• TCD = 3
• TPL = 3
• TCL = 4

结论：

• TCL = 4，可以使用
• 需要额外的验证措施

ASIL 导向分析的指南

FMEA 的示例

示例：制动系统的 FMEA

FTA 的示例

示例：制动系统的 FTA

顶层事件：制动失效导致无法停车

故障树：

        制动失效
           │
      ┌────┴────┐
      │         │
   液压失效   电子失效
      │         │
   ┌───┴───┐ ┌─┴────┐
   │       │ │      │
主缸失效 管路泄漏 CPU故障
   │       │ │      │
  ○       ○ ○      ○

最小割集：

1. {主缸失效}
2. {管路泄漏}
3. {CPU 故障}

STPA 的示例

示例：制动系统的 STPA

不安全控制行为（UCAs）：

1. 提供不正确的制动力
2. 在错误的时间提供制动力
3. 制动力持续时间过长或过短

导致 UCAs 的原因：

常见问题和最佳实践

常见问题

问题 1：如何确定 ASIL 等级？

回答： ASIL 等级通过危害分析和风险评估（HARA）确定，基于三个维度：严重性（S）、暴露率（E）、可控性（C）。使用 ASIL 确定矩阵确定 ASIL 等级。

问题 2：ASIL 分解的规则是什么？

回答： ASIL 分解是一种将高 ASIL 要求分配到不同架构元素的技术。分解规则：

• ASIL D 可以分解为 ASIL D + ASIL C 或 ASIL D + ASIL B 或 ASIL D + ASIL A
• ASIL C 可以分解为 ASIL C + ASIL B 或 ASIL C + ASIL A
• ASIL B 可以分解为 ASIL B + ASIL A

前提条件：

• 分解的架构元素必须相互独立
• 分解的架构元素必须有充分的设计自由度

问题 3：如何计算硬件架构指标（SPFM、LFM）？

回答：

SPFM（单点故障度量）： $$ \text{SPFM} = \frac{\sum \lambda_{\text{SPF}} - \sum \lambda_{\text{RF}}}{\sum \lambda_{\text{SPF}}} \times 100% $$

LFM（潜在故障度量）： $$ \text{LFM} = \frac{\sum \lambda_{\text{LF}} - \sum \lambda_{\text{RF}}}{\sum \lambda_{\text{LF}}} \times 100% $$

其中：

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

最佳实践

1. 系统化地应用标准

   • 建立流程
   • 使用工具
   • 文档化

2. 参考行业最佳实践

   • 参考汽车厂商的经验
   • 参考供应商的经验
   • 参考认证机构的经验

3. 定期培训和学习

   • 定期参加培训
   • 定期学习新知识
   • 定期分享经验

4. 持续改进

   • 定期回顾项目
   • 总结经验教训
   • 改进流程和方法

总结

ISO 26262-10 指南部分为实际应用 ISO 26262 标准提供了详细的解释、示例和最佳实践。通过本文的深入解读和丰富的案例实践，我们掌握了：

1. 概念阶段的指南：

   • 危害分析（HARA）的示例
   • ASIL 确定的示例
   • 功能安全概念的示例

2. 系统级开发的指南：

   • 系统架构设计的示例
   • 技术 安全概念的示例
   • 系统集成和测试的示例

3. 硬件级开发的指南：

   • 硬件架构设计的示例
   • FMEDA 分析的示例
   • 硬件架构指标计算的示例

4. 软件级开发的指南：

   • 软件架构设计的示例
   • 软件单元测试的示例

5. 生产和运行的指南：

   • 生产一致性的示例

6. 支持过程的指南：

   • 配置管理的示例
   • 文档管理的示例
   • 工具置信度评估的示例

7. ASIL 导向分析的指南：

   • FMEA 的示例
   • FTA 的示例
   • STPA 的示例

8. 常见问题和最佳实践：

   • 常见问题的解答
   • 最佳实践的总结

核心要点：

• ISO 26262-10 提供了详细的指南和示例，帮助正确理解和应用标准
• 参考 ISO 26262-10 可以避免很多常见的错误和陷阱
• 最佳实践是持续学习、持续改进
• 系统化地应用标准，建立流程、使用工具、文档化

在下一篇文章中，我们将深入解读 ISO 26262-11 半导体部分，学习如何分析和评估半导体的功能安全。

延伸阅读

• ISO 26262-1: 词汇
• ISO 26262-2: 功能安全管理
• ISO 26262-11: 半导体
• ISO 26262 整体综述