ISO 26262

ISO 26262 标准概览

标准全称	道路车辆 功能安全 (Road vehicles — Functional safety)
核心定义	避免因电气/电子系统故障导致的危害风险
关键指标	ASIL (A/B/C/D) 等级
V 模型	全生命周期管理（概念、开发、生产、运行、报废）
目标	实现系统级安全（Safe State）

ISO 26262 是汽车行业针对道路车辆电子电气（E/E）系统安全领域最顶层的功能安全国际标准。它起源于通用 IEC 61508 标准，但针对汽车工业的特殊需求进行了量身定制。该标准的核心逻辑在于：通过严密的开发流程与技术规范，将系统因电气电子故障导致的危害事件（Hazardous Events）风险降低至可接受的水平。

在智能网联汽车的量产门槛中，ISO 26262 的认证等级是衡量软硬件是否具备上车资格的最高技术评价标准。

1. 核心核心概念与评估指标

ISO 26262 并非单纯测试产品的电气性能，而是评估整个工程化体系的安全性。

1.1 ASIL 等级 (Automotive Safety Integrity Level)

这是衡量安全风险的核心参数。ASIL 等级基于严重度（Severity）、暴露率（Exposure）和可控性（Controllability）进行综合判定：

• ASIL A：最低安全完整性要求。
• ASIL D：最高安全完整性要求（如自动驾驶决策、转向控制、制动系统）。要求必须具备冗余设计、严密的软件静态检查及代码覆盖率验证。

1.2 功能安全生命周期 (Safety Lifecycle)

ISO 26262 贯穿产品的全生命周期：

• 概念阶段：进行危害分析与风险评估（HARA），定义安全目标（Safety Goals）。
• 系统/软硬件开发阶段：基于 V 模型，从需求、设计、实现到验证。
• 生产与运行阶段：确保在量产制造及车辆售后服役期间，安全架构依然有效。

---

2. 软硬件开发的技术红线

ISO 26262 要求在开发过程中采取强制性的安全措施，以防御随机硬件失效（Random Hardware Failures）与系统性失效（Systematic Failures）。

2.1 硬件安全架构设计

为了达到 ASIL 等级要求，硬件方案通常需要：

• 冗余设计 (Redundancy)：双核对比（Lock-Step）架构，或者跨控制器异构冗余。
• 故障监测机制：利用内置自检（BIST）、外部窗口看门狗、电压监测等电路，在故障发生时进入安全状态（Safe State）。

2.2 软件安全编码规范 (MISRA C)

软件实现是 ISO 26262 中的难点。要求：

• MISRA C 规范：严禁使用不确定性高的 C 语言特性（如指针直接偏移、动态内存分配 `malloc` 等）。
• 代码覆盖率 (Code Coverage)：对于 ASIL D 项目，必须满足 100% 的语句覆盖（Statement）、分支覆盖（Branch）甚至 MC/DC 覆盖。

---

3. 硬件工程师的“安全合规”Checklist

在进行满足 ISO 26262 功能安全目标的硬件设计时，必须在需求阶段确认：

1. 安全需求分解（Safety Requirements Decomposition）：不要将所有功能视为安全关键。应使用 ASIL 分解方法，将安全需求从高层级系统目标（Safety Goal）逐层映射到硬件需求（HSR）和软件需求（SSR）。
2. 故障率分析 (FMEDA)：执行失效模式、影响及诊断分析（FMEDA）。不仅要分析单点失效（Single Point Fault），还必须计算单点故障指标（SPFM）和潜伏故障指标（LFM），确保硬件满足 ASIL 等级对应的统计学概率阈值。
3. 软硬件接口协议（HSI）：明确硬件提供给软件的资源分配，特别是针对中断响应时间、内存保护单元（MPU）的配置，这些是防止软件故障蔓延至硬件物理层面的关键闸门。

---

4. ISO 26262 与其他标准的关系

• AEC-Q100：提供芯片底层的硬件应力耐受度，是 ISO 26262 执行的基础。
• ISO 16750：提供环境适应性边界，确保电子设备在各种气候和物理环境下不发生不可控的初始失效。
• ISO 21448 (SOTIF)：针对预期功能安全。ISO 26262 处理的是“功能故障”，而 SOTIF 处理的是“功能正常但感知受限”造成的安全问题。

参见

• ISO 26262-6 (软件功能安全)
• MISRA C