引言

在汽车电子的世界里，功能安全是一个关乎生命的重要议题。想象一下，当你驾驶汽车以每小时 100 公里的速度行驶在高速公路上，你的 ABS（防抱死制动系统）突然失效，或者动力转向突然不工作，这些情况都可能导致灾难性的后果。为了防止这些情况的发生，国际标准化组织制定了 ISO 26262 标准，而这一系列的第一部分——ISO 26262-1 词汇，就是理解整个标准的基础。

你可能会有这样的疑问：为什么词汇部分如此重要？ 让我们用一个简单的比喻来说明。就像学习一门新的编程语言，首先需要理解其语法和关键字一样，ISO 26262 的每一个术语都有其精确的定义和特定的含义。如果不能准确理解这些术语，就无法正确应用后续各个部分的要求。

在本文中，我们将深入解读 ISO 26262-1 的核心术语，通过丰富的案例实践，让你不仅理解这些术语的定义，更能掌握它们在实际工程中的应用。

核心概念：功能安全的本质

什么是功能安全？

ISO 26262-1 将**功能安全（Functional Safety）**定义为：

不存在因电子电气系统故障导致的不合理风险

这个定义看似简单，但包含了几个关键的要素：

  1. 风险的不合理性：不是所有风险都要完全消除，而是要将风险降低到"合理"的水平
  2. 电子电气系统：关注的是 E/E 系统（Electrical and Electronic systems）
  3. 故障导向：关注的是系统可能发生的故障行为

让我们用一个实际的例子来说明。

案例：汽车制动系统

假设我们正在设计一个电动车的制动系统。这个系统包含：

  • 机械制动（主缸、刹车片等）
  • 电子制动控制（ABS、ESP 等控制器）
  • 传感器（轮速传感器、压力传感器等）

功能安全的目标是确保：即使电子控制系统出现故障，车辆仍然能够被驾驶员安全地制动。

如果 ABS 控制器发生故障，系统进入降级模式，但基本的制动功能仍然有效，那么这就满足了功能安全的要求。

安全目标（Safety Goal）

安全目标是 ISO 26262 中最顶层的安全要求。它描述了为了实现功能安全，必须达到的具体目标。

案例：动力转向系统安全目标

对于电动助力转向系统（EPS），一个典型的安全目标可能是：

“在所有可预见的使用场景下，EPS 系统的故障不得导致转向力的突然完全丧失。”

这个安全目标的几个特点：

  • 明确了保护对象：转向力的连续性
  • 明确了风险场景：突然完全丧失
  • 明确了约束条件：所有可预见的使用场景

ASIL：汽车安全完整性等级

ASIL 的四个等级

**ASIL（Automotive Safety Integrity Level，汽车安全完整性等级）**是 ISO 26262 中最核心的概念之一。它将汽车功能安全的严格要求分为四个等级：ASIL A、B、C、D。

ASIL 等级越高，要求的严格程度越高。

ASIL 等级严重程度概率可控性典型应用
ASIL D非常高非常低非常差安全气囊、电子驻车制动
ASIL C高低差ABS 系统、发动机控制
ASIL B中中中车辆稳定控制、照明控制
ASIL A低高好仪表显示、倒车雷达

ASIL 的确定方法

ASIL 等级不是随意指定的，而是通过风险评估（Hazard Analysis and Risk Assessment，HARA） 来确定的。它基于三个维度的评估：

  1. 严重性（Severity）

    • S0：无伤害
    • S1：轻微到中等伤害
    • S2：严重到危及生命的伤害（生存概率高）
    • S3：危及生命的伤害（生存概率不确定）或致命伤害

  2. 暴露率（Exposure）

    • E0：极不可能
    • E1：非常低概率
    • E2：低概率
    • E3：中等概率
    • E4：高概率

  3. 可控性（Controllability）

    • C0：总体可控
    • C1：简单可控
    • C2：正常可控
    • C3：难于控制

案例：制动系统 ASIL 分析

让我们分析一个具体的案例：电动真空助力泵失效

场景描述：当真空助力泵发生故障时，驾驶员需要用更大的力量踩制动踏板才能达到相同的制动力。

ASIL 分析过程：

  1. 严重性（S）：如果助力完全失效，在紧急制动情况下：

    • 刹车距离显著增加
    • 可能导致碰撞事故
    • 结论：S3（危及生命的伤害）

  2. 暴露率（E）：

    • 真空助力泵的工作时间占整个车辆运行时间的 100%
    • 结论：E4（高概率）

  3. 可控性（C）：

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

根据 ASIL 确定矩阵，S3 + E4 + C2 = ASIL C 或 ASIL D（具体取决于对 C2 的细分判定）

这意味着该系统需要按照 ASIL C 或 ASIL D 的要求进行开发。

ASIL 分解（Decomposition）

ASIL 分解是一种将高 ASIL 要求分配到不同架构元素的技术，从而降低每个元素的 ASIL 要求。

案例：双重冗余架构

假设一个功能被确定为 ASIL D。如果采用双通道冗余架构，每个通道可以按照以下规则分解：

$$ \text{ASIL D} \to \text{ASIL D(x) + ASIL D(y)} $$

其中 $x$ 和 $y$ 是两个独立的架构元素。

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

实际应用：电子驻车制动系统

  • 主通道：ASIL D
  • 冗余通道：ASIL C
  • 两个通道相互独立，共同实现 ASIL D 的整体要求

故障模型：理解系统失效的根源

ISO 26262 将故障分为两大类：

硬件故障（Hardware Fault）

硬件故障是指硬件元件或子系统的物理失效。可以分为：

  1. 系统故障（Systematic Fault）

    • 由设计或制造过程引起的确定性故障
    • 可以通过改进设计或过程来消除
    • 例如：软件逻辑错误、EMC 设计不当

  2. 随机硬件故障（Random Hardware Fault）

    • 硬件元件随时间推移而发生的不可预测失效
    • 无法完全消除，只能通过安全机制来检测和控制
    • 例如：晶体管老化、焊点失效

案例：随机硬件故障的计算

假设我们要计算一个 MCU（微控制器）的 FIT 率（Failure In Time，每十亿小时故障次数）。

MCU 由多个子系统组成：

  • CPU 核心：10 FIT
  • Flash 存储器：50 FIT
  • SRAM：30 FIT
  • 定时器：5 FIT
  • 外设接口：15 FIT

总 FIT 率计算： $$ \text{FIT}_{\text{total}} = 10 + 50 + 30 + 5 + 15 = 110 \text{ FIT} $$

转换为每小时故障概率： $$ \text{Failure Rate} = \frac{110}{10^9} = 1.1 \times 10^{-7} \text{ 每小时} $$

ASIL D 的硬件架构指标要求（单点故障度量）： $$ \text{SPFM} > 99% $$

这意味着单点故障导致的危险失效概率要小于 $1%$。

软件错误（Software Error）

软件错误是指软件代码中的缺陷或错误，可能导致系统行为异常。

关键区别：软件错误属于系统故障，因为它们是设计缺陷，而非随机故障。

案例：软件错误导致的系统失效

考虑一个简单的控制算法：

// 错误的代码示例
void control_system(int input) {
    int threshold = 1000;
    if (input > threshold) {
        activate_safety_mode();
    }
    // 问题：当 input = 1001 时，触发安全模式
    // 但当 input = -1001 时（溢出），行为未定义
}

如果这是一个 ASIL D 系统的代码，这样的错误是绝对不可接受的。

安全生命周期：V 模型

ISO 26262 采用经典的 V 模型作为安全生命周期的基础。V 模型将开发过程分为：

  1. 左侧阶段：需求定义和设计

    • 概念阶段
    • 系统级设计
    • 硬件/软件设计

  2. 右侧阶段：实现和验证

    • 硬件/软件实现
    • 集成和测试
    • 验证和确认

  3. 连接箭头：测试活动

    • 单元测试
    • 集成测试
    • 系统测试
    • 验收测试

案例：发动机控制系统的 V 模型应用

左侧（设计阶段）：

  1. 概念阶段：

    • 功能安全目标：防止发动机超速
    • 确定安全等级：ASIL C

  2. 系统级设计：

    • 系统架构定义
    • 传感器、控制器、执行器的分配

  3. 硬件/软件设计：

    • 硬件：ECU 设计、传感器选型
    • 软件：控制算法、故障诊断软件

右侧（实现和验证）：

  1. 硬件/软件实现：

    • ECU 硬件制造
    • 软件编码

  2. 集成和测试：

    • 硬件在环测试（HIL）
    • 软件在环测试（SIL）

  3. 验证和确认：

    • 整车测试
    • 安全目标验证

安全机制：检测和控制故障

安全机制的定义

安全机制是指用于检测、控制或减轻故障后果的技术措施。

安全机制的类型：

  1. 故障检测机制

    • 例如：看门狗定时器、奇偶校验

  2. 故障容错机制

    • 例如：冗余系统、投票机制

  3. 故障响应机制

    • 例如：安全状态切换、报警

案例：看门狗定时器（Watchdog Timer）

看门狗定时器是最常见的安全机制之一。

工作原理：

  1. 正常操作时，软件定期"喂狗"（重置看门狗定时器）
  2. 如果软件出现故障（死循环、死锁等），无法及时喂狗
  3. 看门狗定时器超时，触发系统复位或进入安全状态

代码示例：

// 伪代码：看门狗喂狗
void main_loop() {
    while(1) {
        execute_control_logic();

        // 定期喂狗（例如每 10ms）
        if (timer_expired(10ms)) {
            watchdog_feed();
        }

        // 如果控制逻辑卡死，watchdog_feed() 不会执行
        // 看门狗定时器超时，触发系统复位
    }
}

ASIL 要求：

  • ASIL A：不强制要求看门狗
  • ASIL B：推荐使用看门狗
  • ASIL C：必须使用外部看门狗
  • ASIL D：必须使用外部看门狗 + 额外的安全机制

案例：三模冗余（Triple Modular Redundancy，TMR）

三模冗余是 ASIL D 系统常用的安全机制。

基本原理：

  • 使用三个相同的执行单元
  • 通过"少数服从多数"的投票机制
  • 可以容忍一个单元的故障

可靠性分析：

假设每个单元的可靠度为 $R$（例如 $R = 0.99$）。

系统可靠度 $R_{\text{system}}$ 的计算：

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

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

代入数值： $$ R_{\text{system}} = 0.99^3 + 3 \times 0.99^2 \times 0.01 $$ $$ R_{\text{system}} = 0.970299 + 3 \times 0.9801 \times 0.01 $$ $$ R_{\text{system}} = 0.970299 + 0.029403 $$ $$ R_{\text{system}} = 0.999702 $$

可以看到，单个单元的可靠度为 99%，但通过三模冗余，系统可靠度提升到了 99.97%。

故障树分析（FTA）

故障树分析是一种自顶向下的演绎分析方法，用于分析系统失效的原因。

案例：制动系统失效分析

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

故障树构建：

制动失效
├── 液压系统失效
│   ├── 主缸故障
│   ├── 管路泄漏
│   └── 刹车片磨损
├── 电子控制失效
│   ├── ABS 控制器故障
│   ├── 传感器故障
│   └── 执行器故障
└── 驾驶员操作失误
    ├── 反应时间不足
    └── 操作错误

定性分析：识别导致顶层事件的最小割集（Minimal Cut Sets）

定量分析：计算顶层事件的发生概率

假设：

  • 主缸故障概率：$10^{-6}$
  • ABS 控制器故障概率：$10^{-5}$
  • 传感器故障概率：$10^{-4}$

制动失效概率（简化模型）： $$ P(\text{制动失效}) \approx 10^{-6} + 10^{-5} + 10^{-4} = 1.11 \times 10^{-4} $$

FMEA：失效模式与影响分析

**FMEA（Failure Mode and Effects Analysis）**是一种自底向上的分析方法，用于识别系统组件的潜在失效模式及其影响。

案例：转向系统 FMEA 表

组件失效模式失效原因局部影响系统影响严重度检测方法推荐措施
转向电机卡死轴承磨损无助力转向困难8电流监测双电机冗余
角度传感器信号漂移温度变化角度误差转向不精确6冗余传感器三重传感器
ECU 电源过压保护触发负载突变系统重启短时失去助力7电源监测UPS 电容
CAN 总线通信中断EMI 干扰数据丢失控制失效9心跳监测双 CAN 冗余

安全目标与功能安全要求的关系

层次结构

ISO 26262 定义了一个完整的需求层次：

  1. 功能安全需求（FSR）：从安全目标衍生而来
  2. 技术安全需求（TSR）：将 FSR 分配到硬件和软件
  3. 硬件安全需求（HSR）：针对硬件的具体实现
  4. 软件安全需求（SSR）：针对软件的具体实现

案例：防抱死制动系统（ABS）

安全目标（SG）：

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

功能安全需求（FSR-1）：

“当检测到 ABS 控制器故障时，系统应在 100ms 内切换到纯机械制动模式”

技术安全需求（TSR-1）：

“硬件应实现双通道控制器架构，每个通道独立监测”

硬件安全需求（HSR-1）：

“MCU 应具备独立于 CPU 的看门狗定时器”

软件安全需求（SSR-1）：

“控制循环应包含故障诊断算法，检测超限应在 50ms 内完成”

验证与确认（Verification and Validation）

验证（Verification）

验证回答的问题是：“我们是否正确地构建了产品？”

验证方法：

  • 代码审查
  • 静态分析
  • 单元测试
  • 集成测试

确认（Validation）

确认回答的问题是：“我们是否构建了正确的产品？”

确认方法：

  • 系统测试
  • 整车测试
  • 实车道路测试

案例：转向控制系统的验证与确认

验证活动：

  1. 代码审查：

    • 检查代码是否符合 MISRA C 规范
    • 确保所有 ASIL C 要求已实现

  2. 静态分析：

    • 使用 Coverity 或类似工具检测潜在缺陷
    • 复杂度分析：圈复杂度 < 15

  3. 单元测试：

    • 测试覆盖率：语句覆盖率 > 90%
    • 分支覆盖率 > 85%

确认活动：

  1. HIL 测试：

    • 测试各种传感器故障场景
    • 验证安全状态切换的正确性

  2. 整车测试：

    • 在不同路况下测试转向性能
    • 低附着力路面测试
    • 高速紧急避让测试

  3. 实车道路测试：

    • 累计测试里程：> 50,000 km
    • 不同气候条件测试（高温、低温、高湿）

总结

ISO 26262-1 词汇部分提供了理解整个功能安全标准的语言基础。通过本文的深入解读和丰富的案例实践，我们掌握了：

  1. 核心术语：

    • 功能安全、安全目标、ASIL 等级
    • 故障模型、安全机制
    • V 模型、验证与确认

  2. ASIL 分析方法：

    • 基于 S、E、C 三个维度的风险评估
    • ASIL 分解技术
    • 具体系统的 ASIL 确定案例

  3. 实际应用：

    • 制动系统 ASIL 分析
    • 看门狗定时器机制
    • 三模冗余的可靠性计算
    • 故障树分析和 FMEA

掌握这些词汇和概念，是深入学习和应用 ISO 26262 其他部分的基础。在接下来的文章中，我们将深入解读 ISO 26262 的每一个部分，帮助你构建完整的汽车功能安全知识体系。

延伸阅读