ISO 26262-3 概念阶段：功能安全的基石

引言

在汽车电子系统的开发过程中，概念阶段（Concept Phase） 是整个功能安全流程的起点和基石。就像建造摩天大楼必须先打好地基一样，如果概念阶段的工作做得不扎实，后续的系统设计、硬件实现、软件开发都可能建立在错误的基础上。

想象一个真实的场景：某汽车厂商开发了一款新型电动车，其智能制动系统采用了先进的电子控制技术。但是，由于在概念阶段没有充分分析"制动助力失效"这个危害，导致在实际使用中，当电子真空助力泵突然失效时，驾驶员需要用正常情况下3-4倍的力度才能踩下刹车踏板，这在紧急情况下可能导致严重事故。

这个案例告诉我们：**概念阶段的核心使命是识别所有潜在的危害，评估其风险，并制定相应的安全目标和安全概念。**这正是 ISO 26262-3 要解决的问题。

概念阶段的目标和范围

概念阶段的核心活动

ISO 26262-3 定义了概念阶段的五个核心活动：

1. 危害分析和风险评估（HARA）

   • 识别系统功能相关的潜在危害
   • 评估每个危害的风险等级
   • 确定每个危害的 ASIL 等级

2. 功能安全概念（FSC）

   • 定义功能安全需求
   • 将安全需求分配到系统架构
   • 确定安全机制

3. 功能安全需求（FSR）

   • 从安全目标派生具体的安全需求
   • 建立需求追溯关系

4. 车辆集成

   • 定义安全相关的车辆级别接口
   • 确保与整车其他系统的兼容性

5. 安全确认

   • 验证安全概念的有效性
   • 确认安全目标的达成

概念阶段的输入和输出

输入

• 功能规范：描述系统要实现的功能
• 车辆规范：整车级别的规范和要求
• 法律和法规要求：如 ECE R13（制动系统）、ECE R79（转向系统）等
• 相关方需求：来自 OEM、供应商、法规部门的需求
• 经验教训：类似项目的历史数据和失效案例

输出

• HARA 报告：危害分析和风险评估报告
• 功能安全概念（FSC）：文档化的功能安全概念
• 功能安全需求（FSR）：具体的安全需求规格说明
• 安全目标清单：所有安全目标的汇总
• 车辆接口规范：与整车相关的接口定义

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

危害识别

危害识别是 HARA 的第一步，需要系统地识别所有可能由系统故障导致的危害。

危害识别方法

1. 功能分析：

   • 列出系统的所有功能
   • 分析每个功能在正常、异常、故障状态下的行为

2. 场景分析：

   • 考虑不同的驾驶场景（城市道路、高速公路、恶劣天气等）
   • 分析系统在不同场景下的潜在失效影响

3. 故障模式分析：

   • 系统性分析每个组件的故障模式
   • 评估故障传播路径

案例：电动助力转向系统（EPS）的危害识别

系统功能：

• 辅助驾驶员转向
• 提供不同车速下的助力调节
• 实现主动回正和转向阻尼

潜在危害：

风险评估（ASIL 确定）

风险评估基于三个维度：严重性（Severity）、暴露率（Exposure）和可控性（Controllability）。

严重性评估标准

暴露率评估标准

可控性评估标准

ASIL 确定矩阵

根据 S、E、C 三个维度的组合，从 ASIL 确定矩阵中确定 ASIL 等级：

注意：QM（Quality Management）表示不需要按照功能安全标准开发，但需要符合质量管理体系（如 IATF 16949）。

案例：制动系统 HARA 实践

让我们以**电子液压制动系统（EHB）**为例，详细展示 HARA 过程。

危害 1：制动助力完全失效

场景描述：在高速公路上以 100 km/h 的速度行驶时，突然需要紧急制动，但制动助力系统失效，驾驶员需要用正常情况 5 倍的力度踩刹车。

风险评估：

1. 严重性（S）：

   • 制动距离增加 20-30 米
   • 可能导致追尾碰撞
   • 结论：S3（危及生命的伤害）

2. 暴露率（E）：

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

3. 可控性（C）：

   • 未经过训练的驾驶员可能反应不足
   • 紧急情况下，心理压力影响判断
   • 结论：C2（正常可控到难于控制之间）

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

安全目标：

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

危害 2：制动误动作（意外制动）

场景描述：车辆在高速公路巡航时，制动系统突然自动施加制动力，导致车辆急剧减速，可能引发后车追尾。

风险评估：

1. 严重性（S）：

   • 后车追尾可能导致严重伤害
   • 车辆失控可能引发连环事故
   • 结论：S3（危及生命的伤害）

2. 暴露率（E）：

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

3. 可控性（C）：

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

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

安全目标：

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

功能安全概念（FSC）

FSC 的定义和作用

功能安全概念（FSC） 是为了实现安全目标而定义的总体策略和方法。它描述了：

1. 如何防止危害的发生
2. 如何检测危害
3. 如何控制或减轻危害的后果

FSC 的组成部分

1. 功能安全需求（FSR）

从安全目标派生而来的具体需求。

2. 安全机制

用于检测和控制故障的技术措施。

3. 容错时间间隔（FTTI）

从故障发生到危险事件发生之间的时间窗口。

4. 安全状态

系统在检测到故障后进入的安全模式。

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

FTTI 是一个关键概念，它定义了系统在检测到故障后有多长时间来采取安全措施，以避免危险事件的发生。

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

案例：制动系统的 FTTI 计算

对于"制动误动作"这个危害：

• 故障检测时间：

  • 传感器采样周期：10 ms
  • 故障诊断算法执行时间：5 ms
  • 总计：15 ms

• 故障处理时间：

  • 决策逻辑执行时间：5 ms
  • 命令发送时间：5 ms
  • 总计：10 ms

• 安全状态转换时间：

  • 阀门关闭时间：50 ms
  • 压力释放时间：50 ms
  • 总计：100 ms

总 FTTI： $$ \text{FTTI} = 15 + 10 + 100 = 125 \text{ ms} $$

风险分析： 如果驾驶员以 100 km/h（约 27.8 m/s）的速度行驶，在 125 ms 内车辆行驶的距离： $$ d = v \times t = 27.8 \times 0.125 = 3.475 \text{ m} $$

这意味着系统必须在 3.5 米内检测到并处理故障，这在高速情况下非常困难。因此，需要：

1. 缩短故障检测时间（提高采样频率）
2. 优化故障处理算法
3. 使用更快的执行器

安全状态的确定

安全状态是指系统在检测到故障后进入的安全模式。

安全状态的类型

1. 停机状态：系统完全停止工作
2. 降级状态：系统以降级模式运行
3. 报警状态：系统发出报警，但不采取自动措施

案例：转向系统的安全状态

对于电动助力转向系统，可能的安全状态：

功能安全需求（FSR）的制定

FSR 的层次结构

安全目标（Safety Goal）
    ↓
功能安全需求（FSR）
    ↓
技术安全需求（TSR）
    ↓
    ├─ 硬件安全需求（HSR）
    └─ 软件安全需求（SSR）

案例：制动系统的 FSR 分解

安全目标（SG-1）：

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

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

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

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

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

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

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

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

“硬件应实现双通道压力传感器，每个通道独立监测”

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

“压力传感器应具备诊断功能，能够检测开路、短路、漂移等故障”

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

“控制算法应每 10 ms 读取一次压力传感器数据，并执行一致性检查”

车辆集成

车辆接口的定义

概念阶段需要定义安全相关的车辆级别接口，包括：

1. 机械接口：安装位置、空间要求、散热要求
2. 电气接口：电源、接地、信号线、EMC 要求
3. 通信接口：CAN/LIN/FlexRay 总线通信协议
4. 人机接口（HMI）：报警指示、驾驶员交互方式

案例：EPS 系统的车辆接口

机械接口：

• 安装位置：转向柱
• 空间要求：不超过 300mm × 200mm × 150mm
• 散热要求：在环境温度 -40°C 至 +85°C 下正常工作

电气接口：

• 电源：12V DC，工作电压 9-16V
• 功耗：最大 500W（转向时）
• 接地：单点接地，接地电阻 < 10mΩ

通信接口：

• CAN 总线：ISO 11898 标准，波特率 500 kbps
• 信号：车速信号、发动机转速信号、ABS 状态信号
• 协议：ISO 15765-4（UDS on CAN）

HMI 接口：

• 故障指示：仪表盘上的 EPS 故障灯（橙色）
• 驾驶员报警：蜂鸣器报警，持续时间 3 秒

车辆级别的兼容性

概念阶段需要确保新系统与整车其他系统的兼容性：

1. ABS/ESP 系统：制动优先功能
2. 发动机控制系统：转向时发动机扭矩补偿
3. ADAS 系统：车道保持辅助与 EPS 的协调
4. 电源管理系统：EPS 启动时的功率管理

安全确认

安全确认的方法

安全确认是验证功能安全概念的有效性，确保安全目标的达成。

1. 审查

审查清单：

• 所有危害是否都已识别？
• 每个 ASIL 等级是否合理？
• 安全目标是否完整且准确？
• FSR 是否都追溯到安全目标？
• 安全机制是否有效？
• FTTI 是否合理？
• 车辆接口是否完整？

2. 仿真

使用仿真工具验证安全概念：

# 伪代码：制动系统故障注入仿真
def simulate_brake_failure():
    # 正常制动
    brake_force = calculate_brake_force(pedal_position=0.8)
    assert brake_force > 5000  # 牛顿

    # 注入故障：助力失效
    inject_fault(assist_motor_failure=True)
    brake_force = calculate_brake_force(pedal_position=0.8)
    assert brake_force < 2000  # 牛顿（显著降低）

    # 验证安全状态切换
    time_to_safety_state = 0
    while not in_safe_state():
        time_to_safety_state += dt
        if time_to_safety_state > FTTI:
            raise Exception("Safety state not achieved within FTTI")

    # 验证机械制动备份
    mechanical_brake_force = calculate_mechanical_brake(pedal_position=0.8)
    assert mechanical_brake_force > 4000  # 牛顿（可接受）

3. 实车测试

在原型车或测试台上进行实车测试：

• 测试场景：各种驾驶工况（城市、高速、山路）
• 测试条件：正常温度、高温、低温、湿度
• 测试内容：故障注入、安全状态切换、报警系统

实战案例：电动车电池管理系统（BMS）的概念阶段

让我们以一个实际项目为例，展示概念阶段的完整流程。

项目背景

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

第一步：功能分析

BMS 的主要功能：

1. 电池状态监测（电压、电流、温度、SOC）
2. 电池均衡
3. 充放电控制
4. 热管理
5. 故障诊断和保护
6. 与整车控制器（VCU）通信

第二步：危害识别

第三步：风险评估

危害 1：电池过热导致起火

场景描述：在高速公路行驶时，电池管理系统未检测到某单体电池过热，导致热失控，最终起火。

风险评估：

1. 严重性（S）：

   • 电池起火可能导致致命伤害
   • 结论：S3

2. 暴露率（E）：

   • 高速行驶时电池发热量大
   • 夏季高温环境加剧
   • 结论：E4

3. 可控性（C）：

   • 一旦热失控，很难控制
   • 驾驶员通常无法察觉
   • 结论：C3

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

安全目标：

“BMS 不得允许任何单体电池温度超过安全阈值，ASIL D”

危害 2：电池过充

场景描述：充电过程中，BMS 未检测到电池已充满，导致过充。

风险评估：

1. 严重性（S）：

   • 过充可能导致电池鼓包、起火
   • 结论：S3

2. 暴露率（C）：

   • 充电场景常见
   • 结论：E4

3. 可控性（C）：

   • 驾驶员可以停止充电
   • 但可能反应不及时
   • 结论：C2

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

安全目标：

“BMS 不得允许电池过充，ASIL C”

第四步：功能安全概念

安全机制：

1. 过温保护：

   • 多点温度监测（每个电池模组 2-3 个温度传感器）
   • 温度梯度监测（检测异常温升）
   • 多级保护策略（报警、限流、切断）

2. 过充保护：

   • 电压精确监测（每个单体电池独立监测）
   • SOC 精确估算（卡尔曼滤波算法）
   • 充电截止策略（恒流-恒压-浮充）

3. 冗余设计：

   • 双路 CAN 通信（主/备通道）
   • 双路电源（主电源 + 备用电容）
   • 双路 MCU（主/备控制器）

第五步：功能安全需求

从安全目标派生的 FSR：

FSR-1.1（来自 SG-1）：

“BMS 应在每个控制循环（10ms）内读取所有温度传感器数据”

FSR-1.2（来自 SG-1）：

“当检测到任何电池温度超过 60°C 时，系统应在 100ms 内进入安全状态”

FSR-1.3（来自 SG-1）：

“安全状态下，BMS 应切断充电回路，并允许放电”

FSR-2.1（来自 SG-2）：

“BMS 应精确测量每个单体电池电压，误差 < 5mV”

FSR-2.2（来自 SG-2）：

“当检测到任何单体电池电压超过 4.2V 时，系统应在 50ms 内切断充电”

第六步：车辆集成

车辆接口定义：

电气接口：

• 高压连接器：ISO 15118 标准
• 低压控制：12V DC，CAN 总线

通信接口：

• 与 VCU：车速、扭矩需求、充电状态
• 与充电机：充电电流、充电电压、充电状态
• 与仪表盘：SOC 显示、故障报警

HMI 接口：

• SOC 显示：仪表盘数字显示
• 充电状态：充电指示灯
• 故障报警：电池故障灯（红色）、高低温警告（黄色）

常见错误和最佳实践

常见错误

1. 危害识别不完整

   • 只关注主要功能，忽视次要功能
   • 未考虑边界条件和极端情况

2. ASIL 确定过于保守

   • 为了"安全"而过度提高 ASIL
   • 导致不必要的成本增加

3. 安全目标不够具体

   • 使用模糊的语言
   • 无法进行验证和测试

4. 忽视接口问题

   • 未考虑与其他系统的兼容性
   • 接口定义不完整

最佳实践

1. 使用结构化方法

   • 使用 FMEA、FTA 等工具辅助危害识别
   • 建立危害清单和风险矩阵

2. 团队协作

   • 跨部门团队参与（系统、硬件、软件、测试）
   • 定期评审和更新

3. 文档化

   • 完整记录决策过程
   • 建立追溯关系

4. 经验积累

   • 建立失效案例库
   • 定期回顾和更新

总结

ISO 26262-3 概念阶段是功能安全开发的基石。通过本文的深入解读和丰富的案例实践，我们掌握了：

1. 概念阶段的核心活动：

   • 危害分析和风险评估（HARA）
   • 功能安全概念（FSC）
   • 功能安全需求（FSR）
   • 车辆集成
   • 安全确认

2. HARA 方法论：

   • 危害识别的系统性方法
   • 基于 S、E、C 的风险评估
   • ASIL 确定矩阵的应用
   • 制动系统和 EPS 系统的 HARA 实践

3. 功能安全概念：

   • FSC 的定义和组成部分
   • 容错时间间隔（FTTI）的计算
   • 安全状态的确定
   • FSR 的层次结构

4. 实战案例：

   • 制动系统 HARA 完整案例
   • BMS 概念阶段完整实践

核心要点：

• 概念阶段是整个功能安全流程的起点，必须做得扎实
• HARA 是概念阶段的核心活动，需要系统地识别所有危害
• ASIL 等级的确定必须基于客观的风险评估，不能主观臆断
• 功能安全概念要具体、可验证、可追溯
• 车辆集成是确保系统兼容性的关键

在下一篇文章中，我们将深入解读 ISO 26262-4 系统级开发部分，学习如何将概念阶段的安全需求转化为具体的技术实现。

延伸阅读

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