我的汽车进步之路——ISO 26262 汽车功能安全标准

ISO 26262 是国际标准化组织发布的道路车辆电子电气（E/E）系统功能安全标准，脱胎于通用工业功能安全标准 IEC 61508，是汽车行业电子系统开发的核心合规框架。它的核心目标是：通过覆盖全生命周期的流程与技术措施，将 E/E 系统失效导致的人身伤害风险降低到可接受的合理水平。

目前主流生效版本为ISO 26262:2018（第二版），在 2011 版基础上扩展了半导体应用指南、摩托车适配等内容，共包含 12 个部分。

一、标准整体架构（12 个部分）

标准分为管理类、核心开发过程类、支持类和指南类四大模块，覆盖从管理到技术、从概念到报废的全维度要求：

部分编号	标准名称	核心定位
Part 1	词汇（Vocabulary）	统一定义所有功能安全专业术语，是全标准的语义基础
Part 2	功能安全管理	贯穿全生命周期的管理要求：企业级安全文化、项目级安全计划、安全组织与职责、安全评审与确认
Part 3	概念阶段	项目前期安全分析：相关项定义、危害分析与风险评估（HARA）、功能安全概念输出
Part 4	系统级产品开发	系统层面安全设计：技术安全概念、系统架构、系统集成与整车安全确认
Part 5	硬件级产品开发	硬件层面安全设计：硬件安全需求、硬件架构度量、随机失效定量分析、硬件测试
Part 6	软件级产品开发	软件层面安全设计：软件安全需求、架构设计、编码实现、各级测试与覆盖率要求
Part 7	生产、运行、服务与报废	量产落地与售后阶段的安全控制：生产一致性、运维更新、报废安全处理
Part 8	支持过程	通用支撑流程：配置管理、变更管理、工具鉴定、SEooC、分布式开发管理
Part 9	ASIL 导向与安全分析	ASIL 分解规则、安全分析方法（FTA/FMEA/FMEDA）、相关失效分析
Part 10	ISO 26262 指南	标准落地的解释与示例，帮助理解条款的实际应用
Part 11	半导体应用指南	针对车规芯片的功能安全适配要求，覆盖芯片设计、制造与验证
Part 12	摩托车适配	针对摩托车场景的标准裁剪与适配规则

二、核心概念与 ASIL 体系

1. 基础定义

功能安全 ：不存在由 E/E 系统功能异常导致的、对人身造成不合理伤害的风险。它只解决系统失效带来的风险，不解决功能本身性能不足的风险。
失效分类 ：
- 系统性失效：由设计缺陷、流程错误、人为失误导致，可复现，软件失效绝大多数属于此类，通过严格的开发流程和设计规范规避。
- 随机硬件失效：元器件在生命周期内随机发生的物理失效（如电阻开路、芯片栅极击穿），通过硬件冗余、诊断监控和定量指标控制。
相关项（Item）：安全分析的顶层对象，指实现特定车辆功能的一组系统（如自动紧急制动系统、电动助力转向系统）。
安全目标（Safety Goal）：危害分析后输出的最高层级安全要求，对应 "避免特定伤害" 的目标，ASIL 等级直接分配给安全目标。
安全状态：系统检测到故障后，进入的无不合理风险的稳定状态（如动力切断、降速跛行）。
故障容错时间间隔（FTTI）：从故障发生到必须进入安全状态的最长允许时间，是安全机制响应速度的核心约束。

2. ASIL 等级体系

ASIL（Automotive Safety Integrity Level，汽车安全完整性等级）是标准的风险分级核心，共分为 5 个等级，严谨度从低到高为： QM → ASIL A → ASIL B → ASIL C → ASIL D

QM（Quality Management）：无额外功能安全要求，仅需遵循常规质量管理流程。
ASIL D：最高等级，对应最高风险，要求最严格的开发流程、最多的安全机制和最充分的验证。

ASIL 评定方法：危害分析与风险评估（HARA）

ASIL 等级不是主观指定的，而是通过危害分析与风险评估（HARA），从三个维度量化风险后推导得出：

维度	全称	等级划分与定义
S	严重度（Severity）	S0：无伤害；S1：轻度至中度伤害；S2：重度至危及生命（大概率存活）；S3：危及生命至致命（存活不确定）
E	暴露度（Exposure）	E0：几乎不会发生；E1：极低概率（罕见场景）；E2：低概率；E3：中等概率；E4：高概率（日常驾驶常遇到）
C	可控性（Controllability）	C0：完全可控；C1：简单可控（99% 以上驾驶员可避免伤害）；C2：通常可控（90% 以上可避免）；C3：难以控制或不可控

评定规则：

只要 S0、E0、C0 任意一项出现，直接判定为 QM。
三个维度等级越高，最终 ASIL 越高；核心锚点：S3+E4+C3 = ASIL D，任意一个维度降一级，ASIL 对应降一级。
典型示例：高速行驶下制动完全失效 → S3（致命）+ E4（高速是日常场景）+ C3（驾驶员难以控制）→ ASIL D。

3. ASIL 分解规则

当安全需求通过多个相互独立的冗余路径实现时，原始高等级 ASIL 可以拆解为多个低等级 ASIL，在保证整车安全水平不变的前提下降低开发成本，规则定义在 Part 9 中。

分解核心前提

两个冗余要素必须满足独立性：不存在共因失效（如同一电源、同一芯片、同一开发团队），否则分解无效，仍需按原始 ASIL 开发。

常见双要素分解组合

分解后的 ASIL 需标注原始等级后缀（如ASIL B(D)表示分解自 ASIL D），常见合法组合如下：

原始 ASIL	合法分解组合（双要素）
ASIL D	D+D、C+C、C+B、B+B
ASIL C	C+C、C+B、B+B
ASIL B	B+B、B+A、A+A
ASIL A	A+A、A+QM

注意：分解可逐级嵌套，但每一层都必须满足独立性要求；系统集成与整车验证仍需按原始 ASIL 等级执行。

三、安全生命周期与 V 模型

ISO 26262 的核心方法论是安全生命周期，采用经典 V 模型结构，实现 "自顶向下设计分解、自底向上验证追溯" 的闭环。

V 模型整体结构

左支（设计分解）：概念阶段 → 系统级开发 → 硬件级开发 + 软件级开发
右支（验证集成）：硬件 / 软件单元测试 → 软硬件集成测试 → 系统集成测试 → 整车安全确认
贯穿全程：功能安全管理、支持过程、安全分析与评审

生命周期的迭代特性

安全生命周期不是一次性瀑布流程：任何阶段的设计变更都需回溯上游，重新开展对应等级的安全分析与影响评估，确保变更不引入新的安全风险。

四、各开发阶段深度解析

1. 概念阶段（Part 3）

这是功能安全的源头阶段，决定了后续所有开发的安全方向，核心回答三个问题：保护什么？有什么危险？如何防护？

相关项定义 明确分析对象的边界、功能、运行场景、外部接口、法律法规要求，划清安全分析的范围。
危害分析与风险评估（HARA） 步骤：识别系统所有故障模式 → 组合所有相关驾驶场景形成危害事件 → 对每个危害事件评定 S/E/C → 推导 ASIL 等级 → 输出对应安全目标。
功能安全概念（FSC） 针对每个安全目标，定义顶层安全策略：
- 故障检测机制、故障响应逻辑
- 安全状态定义、FTTI 时间要求
- 功能安全需求分配到系统要素
- 初步的 ASIL 分配与分解方案

2. 系统级产品开发（Part 4）

将顶层功能安全需求落地为可实现的技术方案，是衔接概念与软硬件开发的桥梁。

技术安全概念（TSC） 把功能安全需求转化为具体技术要求：
- 系统架构设计，明确安全相关要素与非安全要素的隔离
- 定义软硬件接口（HSI），避免软硬件定义不一致导致集成错误
- 部署系统级安全机制：如传感器冗余、通信校验、状态监控、降级策略
系统集成与测试 将硬件、软件集成后开展系统级测试，验证技术安全需求是否全部实现。
安全确认 在整车环境下验证安全目标是否达成，证明系统在真实场景下的风险处于可接受水平。

3. 硬件级产品开发（Part 5）

核心目标是控制随机硬件失效，通过定量度量指标验证硬件架构的安全完整性。

硬件三大核心安全度量

这是硬件功能安全的定量核心，ASIL C/D 为强制要求，ASIL A/B 为推荐要求：

度量指标	全称	含义	ASIL B 要求	ASIL C 要求	ASIL D 要求
SPFM	单点故障度量	安全机制对单点故障的覆盖比例，反映系统直接抗失效能力	≥90%	≥97%	≥99%
LFM	潜在故障度量	安全机制对多点潜伏故障的覆盖比例，反映双故障叠加的风险防控能力	≥60%	≥80%	≥90%
PMHF	随机硬件失效概率度量	安全目标违反的平均每小时失效率，单位 FIT（1 FIT = 10⁻⁹次 / 小时）	<100 FIT	<100 FIT	<10 FIT

TIF，预期功能安全）
- ISO 26262 解决系统失效导致的风险（如传感器坏了、软件跑飞了）。
- ISO 21448 解决功能本身不足导致的风险（如传感器没坏，但识别不出特殊障碍物）。二者互补，共同覆盖智能驾驶系统的安全风险。
与 ASPICE
- ASPICE 关注软件开发过程的质量与能力成熟度。
- ISO 26262 在过程质量基础上，额外增加了安全专项的技术与管理要求。满足功能安全通常需要先达到一定的 ASPICE 能力等级。